On 6/13/2019 12:51 PM, Timon Gehr wrote:
> On 13.06.19 21:44, Walter Bright wrote:
>> On 6/13/2019 4:30 AM, Timon Gehr wrote:
>>> Yes. IMHO this shouldn't be a @safe pure operation.
>>
>> D regards converting a pointer to an int as safe, but not the other way around.
> 
> I know, and that is fine, but casting a pointer to int is not pure. It glances into the global state maintained by the memory allocator.

We had a discussion a while back about whether allocating memory via new was pure or not, since a different value was produced each time. We eventually took the pragmatic route that pure functions would be next to useless if this was not allowed.

On 6/13/2019 1:25 PM, Timon Gehr wrote:
> On 13.06.19 09:27, Walter Bright wrote:
>> The spec's wrong, because it doesn't do that.
> 
> Memory safety implies no undefined behavior. The only way the spec can be wrong [1] is if you say that corrupting memory has defined behavior in D, in which case the spec would be too weak, and not too strong like you are implying. Otherwise, "memory safe" and "no undefined behavior" are equivalent.

I've already agreed that an uninitialized int should have an undefined value, not undefined behavior :-)

The spec does indeed lack precision with these terms, and it's something well worth addressing.


> [1] Assuming here that we accept that @safe successfully protects against memory corruption, ignoring assumptions that need to be made on @trusted functions.

The spec should be clear that @trusted functions must present an @safe interface.

On Thursday, June 13, 2019 3:49:56 PM MDT Walter Bright via Digitalmars-d wrote:
> On 6/13/2019 1:25 PM, Timon Gehr wrote:
> > On 13.06.19 09:27, Walter Bright wrote:
> >> The spec's wrong, because it doesn't do that.
> >
> > Memory safety implies no undefined behavior. The only way the spec can be wrong [1] is if you say that corrupting memory has defined behavior in D, in which case the spec would be too weak, and not too strong like you are implying. Otherwise, "memory safe" and "no undefined behavior" are equivalent.
> I've already agreed that an uninitialized int should have an undefined value, not undefined behavior :-)
>
> The spec does indeed lack precision with these terms, and it's something well worth addressing.

That doesn't change the fact that @safe code needs to disallow undefined behavior. It just means that we need to be better about how things are defined so that operations that don't need to be classified as having undefined behavior aren't classifed as such, including specifying cases where something has an undefined value but doesn't have undefined behavior. So, while I think that the spec should be clarified to indicate that the purpose of @safe is to guarantee memory safety rather than guaranteeing that there's no undefined behavior, it still looks to me like it needs to require that there be no undefined behavior in @safe code.

- Jonathan M Davis

On Thu, Jun 13, 2019 at 7:35 AM Nemanja Boric via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Thursday, 13 June 2019 at 13:32:05 UTC, Joseph Rushton Wakeling wrote:
> > On Thursday, 13 June 2019 at 08:24:38 UTC, Nicholas Wilson wrote:
> >> No: the spec disagrees with the implementation, therefore at least one of them is wrong. It does not immediately follow that it is the spec that is in error.
> >
> > It's reasonable to say in this case that the spec is in error, because Walter has always been 100% clear that @safe refers only to memory safety, and the implementation reflects that intent.
>
> Not really:
>
> https://issues.dlang.org/show_bug.cgi?id=19326
>
> > tupleof is known to break through private access protections. It should probably not be allowed in @safe code.

Wait... what?
"tupleof is known to break through private access protections. It
should probably not be allowed in @safe code." - Walter Bright

Breaking private access is not in any way shape or form a memory safety violation.

On Thu, Jun 13, 2019 at 12:10 PM Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 6/13/2019 1:24 AM, Nicholas Wilson wrote:
> > No: the spec disagrees with the implementation, therefore at least one of them is wrong. It does not immediately follow that it is the spec that is in error.
>
> @safe has always been about memory safety. The spec is wrong.

"tupleof is known to break through private access protections. It should probably not be allowed in @safe code." - Walter Bright

On Thursday, June 13, 2019 4:27:46 PM MDT Manu via Digitalmars-d wrote:
> On Thu, Jun 13, 2019 at 7:35 AM Nemanja Boric via Digitalmars-d
>
> <digitalmars-d@puremagic.com> wrote:
> > On Thursday, 13 June 2019 at 13:32:05 UTC, Joseph Rushton
> >
> > Wakeling wrote:
> > > On Thursday, 13 June 2019 at 08:24:38 UTC, Nicholas Wilson
> > >
> > > wrote:
> > >> No: the spec disagrees with the implementation, therefore at least one of them is wrong. It does not immediately follow that it is the spec that is in error.
> > >
> > > It's reasonable to say in this case that the spec is in error, because Walter has always been 100% clear that @safe refers only to memory safety, and the implementation reflects that intent.
> >
> > Not really:
> >
> > https://issues.dlang.org/show_bug.cgi?id=19326
> >
> > > tupleof is known to break through private access protections. It should probably not be allowed in @safe code.
>
> Wait... what?
> "tupleof is known to break through private access protections. It
> should probably not be allowed in @safe code." - Walter Bright
>
> Breaking private access is not in any way shape or form a memory safety violation.

Agreed. It might make it possible to then screw up the memory in an object, but that code would then have to be @trusted. And if it didn't actually doing anything that could screw with the memory of the object, then requiring that it be @trusted makes no sense.

- Jonathan M Davis

On Thu, Jun 13, 2019 at 4:12 PM Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Thursday, June 13, 2019 4:27:46 PM MDT Manu via Digitalmars-d wrote:
> > On Thu, Jun 13, 2019 at 7:35 AM Nemanja Boric via Digitalmars-d
> >
> > <digitalmars-d@puremagic.com> wrote:
> > > On Thursday, 13 June 2019 at 13:32:05 UTC, Joseph Rushton
> > >
> > > Wakeling wrote:
> > > > On Thursday, 13 June 2019 at 08:24:38 UTC, Nicholas Wilson
> > > >
> > > > wrote:
> > > >> No: the spec disagrees with the implementation, therefore at least one of them is wrong. It does not immediately follow that it is the spec that is in error.
> > > >
> > > > It's reasonable to say in this case that the spec is in error, because Walter has always been 100% clear that @safe refers only to memory safety, and the implementation reflects that intent.
> > >
> > > Not really:
> > >
> > > https://issues.dlang.org/show_bug.cgi?id=19326
> > >
> > > > tupleof is known to break through private access protections. It should probably not be allowed in @safe code.
> >
> > Wait... what?
> > "tupleof is known to break through private access protections. It
> > should probably not be allowed in @safe code." - Walter Bright
> >
> > Breaking private access is not in any way shape or form a memory safety violation.
>
> Agreed. It might make it possible to then screw up the memory in an object, but that code would then have to be @trusted. And if it didn't actually doing anything that could screw with the memory of the object, then requiring that it be @trusted makes no sense.

To be clear, I'm not disagreeing with Walter; I agree with him. I'm just pointing out that his position is inconsistent, and this quote is correct. But you have to accept that if this quote is correct, then `= void` shouldn't be @safe either.

On Thursday, June 13, 2019 5:30:43 PM MDT Manu via Digitalmars-d wrote:
> On Thu, Jun 13, 2019 at 4:12 PM Jonathan M Davis via Digitalmars-d
>
> <digitalmars-d@puremagic.com> wrote:
> > On Thursday, June 13, 2019 4:27:46 PM MDT Manu via Digitalmars-d wrote:
> > > On Thu, Jun 13, 2019 at 7:35 AM Nemanja Boric via Digitalmars-d
> > >
> > > <digitalmars-d@puremagic.com> wrote:
> > > > On Thursday, 13 June 2019 at 13:32:05 UTC, Joseph Rushton
> > > >
> > > > Wakeling wrote:
> > > > > On Thursday, 13 June 2019 at 08:24:38 UTC, Nicholas Wilson
> > > > >
> > > > > wrote:
> > > > >> No: the spec disagrees with the implementation, therefore at least one of them is wrong. It does not immediately follow that it is the spec that is in error.
> > > > >
> > > > > It's reasonable to say in this case that the spec is in error, because Walter has always been 100% clear that @safe refers only to memory safety, and the implementation reflects that intent.
> > > >
> > > > Not really:
> > > >
> > > > https://issues.dlang.org/show_bug.cgi?id=19326
> > > >
> > > > > tupleof is known to break through private access protections. It should probably not be allowed in @safe code.
> > >
> > > Wait... what?
> > > "tupleof is known to break through private access protections. It
> > > should probably not be allowed in @safe code." - Walter Bright
> > >
> > > Breaking private access is not in any way shape or form a memory safety violation.
> >
> > Agreed. It might make it possible to then screw up the memory in an object, but that code would then have to be @trusted. And if it didn't actually doing anything that could screw with the memory of the object, then requiring that it be @trusted makes no sense.
>
> To be clear, I'm not disagreeing with Walter; I agree with him. I'm just pointing out that his position is inconsistent, and this quote is correct. But you have to accept that if this quote is correct, then `= void` shouldn't be @safe either.

Well, I fail to see how allowing access to private data is not @safe, since it does not inherently mean that there are going to be problems with memory safety. There are reasons to be unhappy about the access level being ignored, but it isn't a memory safety issue until you actually do something with the private data which isn't memory safe.

Whether = void is a memory safety problem or not should depend on whether it can possibly result in memory being corrupted or not.

But if it it's being argued that it should be considered @safe when assigning void to something like an integer, because it can't corrupt memory even though it's bypassing the protections that the compiler normally gives you, while it's simultaneously being argued that .tupleof should be considered @system just because it's bypassing the protections that the compiler normally gives you, then no, I wouldn't think that that position would qualify as being consistent.

Regardless, IMHO, if @safe is specifically about memory safety, then that's what it should be about. We shouldn't have anything considered @system when the compiler can actually verify that it's memory safe.

- Jonathan M Davis

On 14.06.19 00:27, Manu wrote:
> On Thu, Jun 13, 2019 at 7:35 AM Nemanja Boric via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>>
>> On Thursday, 13 June 2019 at 13:32:05 UTC, Joseph Rushton
>> Wakeling wrote:
>>> On Thursday, 13 June 2019 at 08:24:38 UTC, Nicholas Wilson
>>> wrote:
>>>> No: the spec disagrees with the implementation, therefore at
>>>> least one of them is wrong. It does not immediately follow
>>>> that it is the spec that is in error.
>>>
>>> It's reasonable to say in this case that the spec is in error,
>>> because Walter has always been 100% clear that @safe refers
>>> only to memory safety, and the implementation reflects that
>>> intent.
>>
>> Not really:
>>
>> https://issues.dlang.org/show_bug.cgi?id=19326
>>
>>> tupleof is known to break through private access protections.
>>> It should probably not be allowed in @safe code.
> 
> Wait... what?
> "tupleof is known to break through private access protections. It
> should probably not be allowed in @safe code." - Walter Bright
> 
> Breaking private access is not in any way shape or form a memory
> safety violation.
> 

It can very well be if the private data is managed by a @trusted interface that assumes @safe code cannot meddle with that data because it is private.

On Thursday, 13 June 2019 at 21:26:37 UTC, Tim wrote:
> On Thursday, 13 June 2019 at 20:55:34 UTC, Exil wrote:
>> This problem happens because you are used @trusted. If you used @safe you wouldn't be able to increment pointers and modify the values the way you did in @trusted.
>
> Here is a completly @safe version:
>
> import std.stdio;
>
> static int[2] data;
> static int[253] data2;
>
> void test(bool b) @safe
> {
> 	data[b]++;
> }
>
> void main() @safe
> {
> 	bool b = void;
> 	writeln(data, data2);
> 	test(b);
> 	writeln(data, data2);	
> }
>
> If b is valid only data can change. But for me data2 changes, even though it is never written to.

This is a bug. It seems it doesn't do bounds checking for the index because it is a bool value and it is less than the static type. If you change the array to a dynamically allocated one, an assert is hit as expected.