With the current implementation you can accidentally use first heapify_max and then heappop (forgetting the _max), accidentally append something through the normal list append method, change the priority of something unknowing that that breaks the invariant, or run into problems with "Tuple comparison breaks for (priority, task) pairs if the priorities are equal and the tasks do not have a default comparison order".

These headaches could have been mostly removed if these were in a class. And the option to use a custom sequence type could have surely been preserved.

One thing I could imagine would be a kind of "Firefox tab containers" but for flatpak apps. On first launch, you'll have to select what folder will be ~ for it. Folder sharing between those is manual. (And yeah, often forgotten but you can have several users on linux. Sadly, permissions and switching are pain.)

wasm has the additional benefits of allowing something like pre-compiling binaries once on a central server and thus skipping the CPU cycles for compiling all the macro crate dependencies on every crate compile. So even the people who don't care much about the security benefits have a reason. I'm kind of the "don't care about security" side because (as said elsewhere) it's trivial (https://docs.rs/ctor/latest/ctor/) for any macro to insert code that will run when compiled binaries/tests are run. You need the entire thing in a sandbox anyway, not just the macros, and that's something that can't be provided by cargo by default.

(You could have a token that hides previous tokens, but that'd be rather closer to CoT.)

(It mostly boils down to "somebody needs to do it". I'd really like proc macros precompiled to wasm by crates.io…)

(That of course only takes down the "physically impossible" part.)

(Oh and btw, proc macros also run arbitrary code.)

I was expecting something on Binary Decision Diagrams. SAOD is worst with TLAs.