allow-invalid-discriminant.txt

<Havvy> Thought: An attribute for enums that says there are no invalid values for it, but requires `_ =>` in the match always. And then transmuting is legal / using in FFI has less chance of triggering undefined behaviour.
* jonhoo has quit (Quit: Leaving)
<Soni> non-exhaustive enums?
* AstralSorcerer has quit (Ping timeout: 121 seconds)
* aismallard (ammon@moz-e06mkq.vjk9.5piu.1700.2600.IP) has joined
* AstralSorcerer (AstralSorce@moz-3rdpr9.wireless.rochester.edu) has joined
<est31> enums where at definition site you can say
<est31> "this is not the complete list, every match needs to contain a _ => case"
<sfackler> Havvy: there was talk in the non exhaustive enum PR to make #[non_exhaustive] #[repr(C)] behave like that but it didn't make it in. i'd love to have something like that for FFI though
<Havvy> sfackler: Representation hints cannot (should not?) change the validity of `match`, but #[non_exhaustive] #[repr(C)] would do that. So it'd have to be a different attribute.
<sfackler> doesn't #[non_exhaustive] already force a _ => case?
<sfackler> the only difference in the repr(C) case is not telling LLVM that the case can't actually happen
* nagisa has quit (Ping timeout: 121 seconds)
* Zoxc has quit (Ping timeout: 121 seconds)
* badmann (badmann@moz-47502l.dynamic.ziggo.nl) has joined
* sinesc has quit (Ping timeout: 121 seconds)
<nox> RalfJ: Remember our past discussion about pinning and GC tracer running etc?
<Havvy> sfackler: It doesn't enforce it the module (or crate?) that the enum is defined in.
<sfackler> oh right
<Havvy> I guess #[non_exhaustive(always)] could be an extension?
<nox> Havvy: AFAIK that still wouldn't change the fact that an arbitrary enum value would be UB.
<Havvy> nox: Unless matched with a #[repr(C|u8|other primitive)]
<nox> Havvy: What do you mean?
<Havvy> Well, if we define it as such.
<nox> It already has a different definition.
<nox> Or was 'it' the non_exhaustive extension you just suggested?
<Havvy> Yes, that.
<nox> Oh sorry.
<nox> To me that would just mean 'you need to put `_ => ...` in the code that defined it too,
<nox> and that doesn't convey "btw everything goes for that enum values" to me.
<Havvy> So what, we'd still want another attribute e.g. #[allow_invalid_discriminant]?
<nox> Havvy: I would go for that yeah.
<nox> Clang says "open-ended" for those enums.
<nox> Err, slightly misremembered: https://clang.llvm.org/docs/AttributeReference.html#enum-extensibility-clang-enum-extensibility-clang-enum-extensibility
<sfackler> could be #[non_exhaustive(ABI)] or something like that to say that it's non exhaustive at the ABI as well as API lvel
<sfackler> *level
<Havvy> That section title.
<sfackler> haha
<Havvy> nox: Would sfackler's suggestion work?
<nox> Havvy: Convey a fancier meaning than always for sure.
<sfackler> the term ABI there is a bit overly technical though
<sfackler> not sure what a more clear option is though
<Havvy> Well, it can be bikeshedded.