Such as?
AssocTag in rustc_middle::ty - Rust uses "tag". We commonly call enums "tagged unions". Serde talks about tag. Memory layout of enums - Rust for C-Programmers uses discriminant and tag interchangeably.
Also, Discr in rustc_middle::ty::util - Rust demonstrates that we don't want to spell out "discriminant" even inside the compiler.
That's not about enums at all, that uses "tag" in its more general sense.
Yes, and they do have a tag. It's just not the same as their discriminant. Unions are very low-level objects so it's not surprising that a term involving them talks about the low-level representation (tag) rather than the high-level value (discriminant).
And that tag can be a string, so it's clearly not the "discriminant". It is some way to encode which variant is active, just like the tag as defined in the rustc glossary.
Yeah I think that third-party book is just sloppy with its terminology.
I agree that "discriminant" is awkwardly long and annoying to type. We did however accept that in the past in mem::discriminant, so changing course now would mean we use two different terms to refer to the same thing which is generally not a good idea in technical communication, including APIs. And in many contexts, auto-complete will mean that you only have to type #disc or even #d, mitigating the downside of the long name.
I think this inconsistency is my major concern with #tag. We could rename the internal use of "tag" in the compiler to something longer to free up the term (though I don't have a good idea off the top of my head). But using two different nouns for the exact same concept is a bad idea IMO.
1 Like
Once we had .#tag, mem::discriminant would become largely obsolete, so I don't think there'd be any confusion there.
And we deliberately design language features to not rely on IDE features (like completion) for usability.
As a non-expert Rust developer, I think "discriminant" is the more understood term when it comes to Enums. To me "tag" is for "tagged C enums" not Rust Enums. Not saying that is the way it is, I'm just saying that as a non-expert, that's what I've come to understand from the documentation and various other reading.
2 Likes
From what I understand from the proposal, visibility is the main (only?) reason to introduce the new .#discriminant field syntax (and ::#DiscriminantType extension syntax):
While I don't dislike the syntax as such, it seems a rather heavy addition to the language, rather than trying and make trait implementation visibility work, even if special-cased. Or, heck, even auto-implement an inherent discriminant() function with proper visibility until a more generic approach can subsume it.
A more generic option could be to allow reducing the visibility of trait implementations generally, e.g., pub(crate) impl external::SomePublicTrait for MyOtherwisePublicType { ... }.
This would be a good section for me to add 
But the thing that mem::discriminant can do that this one cannot is be used with arbitrary types. If I have an enum with a non-pub discriminant type, you can still mem::discriminant it, even if you can't .#discriminant it.
1 Like