Unions were added to the language post-1.0. union wasn't a reserved keyword, so it was introduced as a weak/contextual keyword for backwards compatibility.
As stated in the reference, dyn was promoted to a strict keyword in 2018 edition. The same wasn't done to union in 2018, 2021, nor 2024.
Is this because no one has been interested in making it happen, or is there a reason (even "vibe based") it hasn't been done? I didn't find anything on Github issues.
I understand that promoting it to a strict keyword would increase languge complexity due to the compiler having to support it contextually in older editions anyway, for a rarely used feature.
(The only reason I even thought about this is that I'm considering naming a struct Union in my code and so it would be mildly annoying if the natural variable name union was changed to a strict keyword in a later edition.)
Oh, that's certainly a good reason to not change it.
Then considering changing union to a strict keyword unlikely, is there a technical reason against relaxing other item keywords (struct, enum, type)? Any parsing ambiguities should be identical to what has to be dealt with anyway because of union, right?
On the one hand, sometimes it’s useful to have something reserved for future purposes we may not even have thought of yet—consider fn’s use for both items and function pointers.
On the other, type sure would be a nice identifier a lot of the time!
Not difficulties in parsing per se, but there is general benefit to having slightly larger edit differences between valid programs. It affects quality error messages in particular. Not that any one of these changes would be necessarily terrible, but I expect the small potential for weird corner cases outweighs my own desire to be able to use struct as a method name.
Sometimes the reason for the way things are is just a bit of historical mishmash.
The big difference is between items and things that happen in expressions.
For various reasons -- a common one being foo { x } being a legal struct initializer -- it's just harder to have unaccompanied contextual keywords in expression contexts than it is in item context.
With my lang hat on (but not speaking for the team officially) I'd be pretty surprised if we ever upgraded union to a full keyword. It's not that useful to do the upgrade, so it wouldn't be worth the extra complication of more edition-dependent parser behaviour.
Rust has a syntax that allows to use reserved keywords as identifiers. It's a bad syntax imo - it's too salty. Nevertheless, it does exist and together with a planned migration plan using editions we should upgrade to proper strict keywords.
Btw, many languages have this feature (e.g Symbol type in JS and Ruby).
The point is: Rust should have a (better) policy around keywords that allows for evolution of the language. dyn is a terrible choice and there's also the re-use and overloading of existing keywords for unrelated features like the new use<> syntax. It shows that the core devs are afarid of evolving the language and adding proper names for features, instead opting to add accidental complexity in the name of "stability" exactly like C++ does with its horrible syntax choices (co_await and co.. )