Actually, I can think of a theoretical feature that would conflict with unsafe union: being able to prepend unsafe to an expression to avoid introducing a new scope. That may or may not be a concern. 
This is veering somewhat tangentially, but is there no larger solution planned for the issue of adding keywords? I remember before 1.0 there were various proposals to pre-reserve swathes of potentially-useful future keywords, which after a point were shut down with the justification, ānah, letās not reserve keywords willy-nilly, instead weāll figure out some way to add keywords to the language after 1.0 without breaking compatibility, such as language versioningā. Now weāre after 1.0, weād like to add keywords but canāt, and thereās no mention of language versioning or any other solution in sight. What happened?
6 Likes
From the RFC:
It would be unsafe for the compiler to assume that a union is a particular variant, therefore it cannot run destructors for any fields in the union.
A possible solution is to add an optional user-defined standard method that gets called to inform the type system what is the current variant to destroy.
And how would you know that from just the union itself? In most cases the tag for the union is stored in the struct which contains the union. Drop on the union itself would never be able to access that tag. Instead what should be done is the struct implements Drop and uses drop_in_place on the correct variant.
1 Like
Update for anyone following the thread but not the associated issues on github: the RFC for unions was accepted and merged today.
2 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.