Totally fair! I mostly get away with it by sharing infrastructure with other backups that I needed anyway.

A sufficiently good backup strategy (redundant, geographically distributed, versioned) is the key to sleeping well with self-hosting. It does take some effort and add cost.

A game and an interactive visualizer for interesting non-euclidean spaces!

You might be interested in projections of hyperbolic spaces. E.g. hyperrogue is pretty neat.

If you spend much time working with actual industrial C code you'll see a lot of patterns that are anything but "zero-cost", too. It's an imaginary ideal.

If I was being graded on a curve against peers who might be spending the maximum possible time, on a test which might have been calibrated to take the maximum possible time, I would feel pressure to spend the maximum possible time too! I like the idea but it's tricky.

But what is an "unclean state"? In the absence of an obvious definition, a doc comment is a great place to lay that out -- or to just specify that an interface is, indeed, cancel-safe.

Is that even a hot take? This seems about as contentious as asking for panics to be documented.

What happens if a feature requirement on a crate is downstream of a property access that forces it to build?

How do you prove that facet APIs can never be used to construct a variant? Seems very difficult, and far beyond what the lint achieves in any other context. Analogous static code would always mention every variant.

Right. Explicitly disabling the lint is bridging that gap, so code that has a similar capability gets linted (or not) in a similar way.

I think it's fair for facet to disable this lint for the same reason e.g. serde::Deserialize effectively would.

How do you soundly determine the proper encoding of the discriminant in the presence of niches?

How does reflection expose the capability to construct a variant without mentioning it? Seems like this must be a fixable clippy oversight.

do tell