[Issue 21565] @safe code allows modification of a scalar that overlaps with a pointer

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=21565

--- Comment #12 from Steven Schveighoffer <schveiguy at gmail.com> ---
(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.

--