[Issue 22045] Assignment of pointers in union should be @safe, only pointers access are @system

d-bugmail at puremagic.com d-bugmail at puremagic.com
Fri Jul 9 14:01:42 UTC 2021


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

--- Comment #2 from Luís Ferreira <lsferreira169 at gmail.com> ---
> I don't really see the point in special casing union pointer assignment
> when
> you cannot access them.

You should be able to safely assign a pointer in a function and never
access it and accessing it elsewhere and when you access it it should
be unsafe there, not the time you assign it.

> I would argue that unions are unsafe by their very
> nature and should be banned completely in @safe code, rather than
> allowing more
> cases.

Why? Unions are memory-safe unless in this case, when you access it.
Memory-safety is about not getting memory corruptions, and if you don't
have pointers, there is never a memory corruption with unions. The
memory is surely overwritten but not corrupted with invalid pointers.

This is literally, by definition, the @safe behaviour described by the
spec: https://dlang.org/spec/memory-safe-d.html

Generally speaking, assignment to lived memory or null is totally @safe
in D.

This behavior is unfortunately getting a lot misconceptions and people
end up missunderstanding @safe in D. See
https://github.com/dlang/phobos/pull/8146

> 
> To be able to distinguish between this 2 cases, dataflow analysis is
> required
> in the compiler to assure the integrity of the b pointer. Walter is
> against
> adding such dataflow analysis in the compiler and frankly I stand by
> him in
> this case.

I don't see the need of complex analysis on this. You simply need this
rule: Assignment to a union is fine, assignment of a union value with
indirections is not fine. This two cases can be disallowed to compile,
for now, but at least the very first one should compile.

Ideally, tracking the pointer reference should be the way here, sure,
but that way, it covers slightly more @safe code and it is impossible
to break it, unless you break other language rules. Additionally, this
would fit the same behaviour of how pointers generally work in D.

Also, sorry for the rant but it is something that bugs me off on this
language is "immutable decisions" based on "immutable opinions" :(
Seeing decisions and features going away simply because either Walter
or Andrei are strongly against it in a community-driven language is not
totally fair. I'm not saying that having strong opinions is bad. I have
strong opinions too. I guess the ideal would be to rationally discuss
them and, in the end, democratically get a valid point out of the
overall opinions.


> My intuition is that this sort of access was initially banned, but bug
> reports
> such as this one asked for the feature therefore it was introduced and
> people
> saw that it does more harm than good and decided to revert it.
> 
> I think that this bug report should be closed as invalid/wontfix.

Either way, the message given by the compiler is wrong, if this end up
not being fixed.

--


More information about the Digitalmars-d-bugs mailing list