https://issues.dlang.org/show_bug.cgi?id=21565
--- Comment #12 from Steven Schveighoffer <[email protected]> --- (In reply to Paul Backus from comment #11) > > Read-only access is fine. Write access is not. > > Again, on what grounds do you make this claim? Can writing to the integer > member cause undefined behavior in @safe-only code? If so, please provide an > example. On the grounds that it's not desirable. It does not cause undefined behavior, just useless behavior. We are better off disallowing it. > What I have in mind is to change the definition of "unsafe value" for unions > to the following: > > > A struct/union instance is safe when: > > > > * the values of its accessible fields are safe, and What does this mean? All individual values are safe according to D. > > * it does not introduce unsafe aliasing with unions that is accessible > > from @safe code. This is not very specific. > This change does not, as far as I can tell, introduce unsoundness into the > language. It does not allow undefined behavior to occur in @safe code. If > you believe I am mistaken about this, please correct me. It's not about being @safe or not. That's why I said the rules are sound. It's just that the rules leave us with the reality that using such unions usable in @safe or @trusted code has no utility. > The reason I call this "sensical" is that *unnecessarily* excluding values > from the definition of "safe value" makes the language more difficult to use > without any benefit to soundness or memory-safety. More difficult than just using an integer instead of a union to represent an integer? > Ideally, we would like > @safe to impose on the programmer only those restrictions that are truly > necessary in order to avoid undefined behavior. There has to be consideration of what semantic meanings the application needs to be able to enforce. Disallowing @safe access to the scalars actually INCREASES the amount of code that is allowed to be marked @safe. That really should be the goal for @safe. Leaving the rules as-is just means such unions, when passed into @trusted code, must treat it the same as @safe code, and therefore they become simply integers. While that's sound, and not allowing undefined behavior, it means writing e.g. a tagged union that has any @safe code is impossible. It must all be @trusted or inferred w/ review. --
