A deeper look into the GCC Rust front-end

Posted Oct 10, 2022 17:21 UTC (Mon) by josh (subscriber, #17465)
In reply to: A deeper look into the GCC Rust front-end by tialaramex
Parent article: A deeper look into the GCC Rust front-end

> Turns out I can make BalancedI8... much more easily than I'd initially assumed - but only with the permanently unstable rustc internal "Here is where the niche lives" attributes which are not available in stable Rust (unless you're the standard library).

I'd love to see that attribute stabilized. The last couple of times we've gotten hung up on all the *future* things we want to support there (e.g. alignment niches), but I think we should *just* support `#[niche(range = "...")]` and allow for the possibility of adding more in the future.

A deeper look into the GCC Rust front-end

Posted Oct 10, 2022 19:36 UTC (Mon) by tialaramex (subscriber, #21167) [Link] (4 responses)

I think a *lot* would be opened up without even a range here, literally just "I promise not to use value = X", reflected internally by the same mechanism used today, but stabilised because hey, realistically Rust will always have a way to do this, it's core to the language proposition, so the stabilised (and presumably unsafe) mechanism can just relay to whatever future mechanism is used, even if that is some day stabilised.

#[simple_niche=0x80]

That's enough to enable the Option-like niche optimisation guarantee, and thus turn all the cases where a C programmer would use a single sentinel value into type safe Rust. There are a lot of cases where saving a few bytes isn't actually important, choosing unstable to do this would be grossly disproportionate. But philosophically, the difference between "There's barely any overhead" and "The machine code is literally identical but thanks to Rust this is type safe" is huge.

A deeper look into the GCC Rust front-end

Posted Oct 10, 2022 22:25 UTC (Mon) by josh (subscriber, #17465) [Link] (3 responses)

The compiler already has an underlying mechanism for specifying a range, it just isn't stabilized. So I think it'd be equally easy to support a range as a single value.

A deeper look into the GCC Rust front-end

Posted Oct 11, 2022 0:38 UTC (Tue) by NYKevin (subscriber, #129325) [Link]

Sure, eventually a range syntax will probably stabilize, but in the meantime, it'd be really nice to have a single-value syntax that's stable and will be supported indefinitely. It could just be defined as syntactic sugar for "whatever the range syntax eventually stabilizes to."

A deeper look into the GCC Rust front-end

Posted Oct 11, 2022 8:16 UTC (Tue) by farnz (subscriber, #17727) [Link] (1 responses)

This feels like the "gotten hung up on all the *future* things we want to support there" comment you made earlier. A single valued niche is not stabilized, is definitely useful, is a subset of things that can reasonably be supported (indeed, it's a subset of things you can support today), and doesn't put as much of a long-term support burden on you as a range, or a more complex way to specify niches.

Perfect as enemy of good, and all that.

A deeper look into the GCC Rust front-end

Posted Oct 11, 2022 9:37 UTC (Tue) by josh (subscriber, #17465) [Link]

The future things (e.g. alignment niches, or whole-null-page niches) are something the compiler doesn't support; delaying to incorporate those would involve new compiler implementation work. The compiler's existing support for niches already supports ranges, so I would expect it to be exactly as easy to support ranges as to support a single value.