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

--- Comment #11 from Paul Backus <snarwin+bugzilla@gmail.com> ---
> 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.

> I just don't know what the definition of "sensical" means, based on your prior messages. What rules do you have in mind?

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
> * it does not introduce unsafe aliasing with unions that is accessible
>   from @safe code.

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.

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. Ideally, we would like @safe to impose on the programmer only those restrictions that are truly necessary in order to avoid undefined behavior.

--

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

--- Comment #12 from Steven Schveighoffer <schveiguy@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.

--

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

--- Comment #13 from Steven Schveighoffer <schveiguy@gmail.com> ---
(In reply to Steven Schveighoffer from comment #12)

> It's just that the rules leave us with the reality that using such unions usable in @safe or @trusted code has no utility.

I rewrote this several times, and it looks terrible. I mean:

It's just that the rules leave us with the reality that such unions in @safe or @trusted code have no utility.

--

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

--- Comment #14 from Paul Backus <snarwin+bugzilla@gmail.com> ---
(In reply to Steven Schveighoffer from comment #12)
> 
> On the grounds that it's not desirable. It does not cause undefined behavior, just useless behavior. We are better off disallowing it.

"I don't like it" is not a technical argument, and should have no place in a technical discussion.

> What does this mean? All individual values are safe according to D.

If you really believe this, then you do not understand D's memory-safety system well enough to contribute usefully to this discussion, and I am wasting both my time and yours by continuing to respond.

> 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.

If it's "not about being @safe or not", then what on Earth *is* it about?

Personally, I think @safe should allow all code that the compiler can prove is memory-safe, regardless of whether you, I, or anyone else thinks it "has utility" or not. I am rather surprised that this is a controversial point of view.

--

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

--- Comment #15 from Steven Schveighoffer <schveiguy@gmail.com> ---
(In reply to Paul Backus from comment #14)
> (In reply to Steven Schveighoffer from comment #12)
> > 
> > On the grounds that it's not desirable. It does not cause undefined behavior, just useless behavior. We are better off disallowing it.
> 
> "I don't like it" is not a technical argument, and should have no place in a technical discussion.

That's not my argument.

> > What does this mean? All individual values are safe according to D.
> 
> If you really believe this, then you do not understand D's memory-safety system well enough to contribute usefully to this discussion, and I am wasting both my time and yours by continuing to respond.

Basic types and pointers are all accessible using @safe. I can access int, int * perfectly fine in @safe code. It's the aliasing of the two that is a problem.

Frankly I think you are misinterpreting what I'm saying, or I am doing the same for you. Wasting time might definitely be what you are doing.

> 
> > 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.
> 
> If it's "not about being @safe or not", then what on Earth *is* it about?

The whole point of @safe is to avoid code review. Otherwise it's a glamorized linter. If you have to review @safe code to make sure things outside the safe code are actually memory safe, then you have lost the battle.

Imagine that D does not have builtin slices (and get rid of the rules safe defines around them). Then you need a structure to pass slices into a @trusted function:

struct Array(T)
{
   T* ptr;
   size_T length;
}

A @trusted function that accepts this type has 2 options:
1. it can't do ANYTHING with the data beyond the one value pointed at by ptr,
because @safe code is allowed to set length to anything it wants.
2. It can use the data beyond the first element, but then you have to review
all @safe functions that call it.

It's the fact that the compiler disallows mutable access to length that we can reason about what this semantically means as a parameter to a @trusted function. Therefore, I don't have to review any array-using safe code for memory safety because I know that the semantic invariant is held by the compiler.

Likewise, a union of an int and an int * semantically MUST mean int today in safe code AND TRUSTED CODE. If you access the int * after any safe code has run with it, it must be considered memory unsafe.

So for instance:

struct S
{
  union X {
   int x;
   int *y;
  }
  X val;

  @safe {
     void a();
     void b();
     void c();
     void d();
  }
  @trusted void e() { /* use val.y */ }
}

How do you review that the usage of val.y is safe? the answer is: you review a, b, c, d, in addition to e. Now you are reviewing safe code to make sure it's safe in the context of val. This is useless. val might as well be an int, or a, b, c, d might as well be marked trusted. So the logical conclusion is, e cannot use val.y. And if it cannot use it, then what's the point of having it?

If we know that a, b, c, and d can never set the value of val.x or val.y, then we don't have to review them at all. Now we are only reviewing e, which is the intent of D's safety system.

I'm not arguing that the current implementation is unsafe, just that the current semantic guarantees make using such unions pointless in the context of safe/trusted code. The point of a union is to use all the members in it. If there is one member that cannot be used, then it shouldn't be part of the union.

> Personally, I think @safe should allow all code that the compiler can prove is memory-safe, regardless of whether you, I, or anyone else thinks it "has utility" or not.

The @safe rules provide a framework for proof of memory safety where we can avoid reviewing whole sections of code. The compiler isn't proving safety, it's just enforcing rules. We create the rules to make sure memory safety cannot be violated even without a careful review of certain functions AND that @safe/@trusted code is reasonable to write with those rules.

For example, let's say we changed the @safe rules to say only arrays and references are allowed to be dereferenced in @safe code, never pointers. Now, safe code can read and write pointers, even write arbitrary values. That's perfectly safe. And perfectly useless. Isn't that just asking to make trusted code even less safe? How does one use @trusted code with a pointer when you can never know if the safe code that passed it to you has just set arbitrary values? What do we gain as a language by allowing setting pointers up as garbage in @safe code?

Such a rule would mean, pointers are safe to use in @trusted functions as long as you don't use them as pointers, only as bits. This is the same rule we are talking about. I don't see why the rule is desirable, and I am surprised that this is a controversial position.

--

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

anonymous4 <dfj1esp02@sneakemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://issues.dlang.org/sh
                   |                            |ow_bug.cgi?id=19916

--

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

anonymous4 <dfj1esp02@sneakemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |19916
           See Also|https://issues.dlang.org/sh |
                   |ow_bug.cgi?id=19916         |


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=19916
[Issue 19916] union member access should be un-@safe
--

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

--- Comment #16 from Paul Backus <snarwin+bugzilla@gmail.com> ---
(In reply to Steven Schveighoffer from comment #15)
> 
> The whole point of @safe is to avoid code review. Otherwise it's a glamorized linter. If you have to review @safe code to make sure things outside the safe code are actually memory safe, then you have lost the battle.

I think this is probably the root of this misunderstanding. There is nothing in the spec (or the implementation) that *requires* you to limit your review to @trusted code. If your proof of memory safety is based on manual review of @safe code, then as far as the language is concerned, that's a perfectly valid proof.

I agree completely that D should make it *possible* for the programmer to limit their checking to @trusted code (see: DIP 1035), and that @trusted code that relies on manual review of @safe code should be subject to close scrutiny. But I think it would be a step too far for the language spec to outright *forbid* anything that requires any manual review of @safe code--especially since there is no practical way the compiler could enforce such a restriction.

--

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

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P2

--

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

--- Comment #17 from dlangBugzillaToGithub <robert.schadek@posteo.de> ---
THIS ISSUE HAS BEEN MOVED TO GITHUB

https://github.com/dlang/dmd/issues/19858

DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB

--