On 6/15/2014 4:26 PM, Timon Gehr wrote:
> On 06/16/2014 01:06 AM, Walter Bright wrote:
>> I don't understand your question. I don't know what is unhelpful about
>> saying that @safe refers to memory safety.
>> ...
>
> You stated the two to be equivalent earlier, which is impossible.

It is for Java, why should D be different?


>> The list is not restricted to syntactic issues.
> (Yes it is,

No, it is not. For example, assigning an int to a pointer is a semantic issue, not a semantic one.


> but that is not important because here the problem here is clearly
> that these terms have wildly different meanings in different communities.)

I don't think the distinction is hard to grasp.


> I'm just trying to find the definition/theorem we do not agree on.

I strongly suggest that you can help by identifying specific issues in bugzilla and marking them with the 'safe' keyword, as I suggested earlier. I do not believe that memory safety is a difficult concept to agree on.

On 6/15/2014 9:49 PM, Walter Bright wrote:
> No, it is not. For example, assigning an int to a pointer is a semantic issue,
> not a semantic one.

Gack, I meant "not a SYNTACTIC one".

On 06/16/2014 06:49 AM, Walter Bright wrote:
> On 6/15/2014 4:26 PM, Timon Gehr wrote:
>> On 06/16/2014 01:06 AM, Walter Bright wrote:
>>> I don't understand your question. I don't know what is unhelpful about
>>> saying that @safe refers to memory safety.
>>> ...
>>
>> You stated the two to be equivalent earlier, which is impossible.
>
> It is for Java,

No. sun.misc.Unsafe can be used to write memory safe code.

> why should D be different?
>
>
>>> The list is not restricted to syntactic issues.
>> (Yes it is,
>
> No, it is not. For example, assigning an int to a pointer is a semantic
> issue, not a [syntactic] one.
>...

By extension, memory safety is a semantic issue. Since it is non-trivial, it is in general not verifiable. (This is Rice's Theorem.)

@safe-ty OTOH is a verifiable property of the program.

> ...
>
>> I'm just trying to find the definition/theorem we do not agree on.
>
> I strongly suggest that you can help by identifying specific issues in
> bugzilla

My point was that no implementation of @safe whatsoever can make it _equivalent_ to memory safety (i.e. @safe will never single out precisely those programs that do not corrupt memory). It will always only approximate memory safety. This is not a bug, it's just a fact.

> and marking them with the 'safe' keyword, as I suggested
> earlier.

In my book, the main problem is that @safe is not specified in a way that is easy to be verified to guarantee memory safety. I think plugging holes one after another as they are discovered in real code  until _hopefully_ none remain is not a very productive use of time. We should strive to keep @safe sound during its whole implementation.

> I do not believe that memory safety is a difficult concept to
> agree on.
>

Why? Many superficially simple informal concepts are difficult to agree on. In this case this is witnessed by the fact that you do not seem to want to ban undefined behaviour from @safe code which I can't agree with.

You have a lot of good thoughts on this issue.

You have specific problems in mind but do not identify them other than in vague terms. I guarantee that I am really, really bad at mindreading.

Instead, I would strongly prefer that you:

1. write bugzilla issues for the problems that you identify

2. connect those bugzilla issues regarding @safe with the 'safe' keyword

3. construct specific proposals for how to fix these issues. The proposals don't actually have to be pull requests, just descriptions on the bugzilla pages for how to fix.

4. write pull requests for the documentation


Even doing just one of 1..4 would be most appreciated. Merely asserting that @safe is broken/buggy/etc. will not result in progress.

On Tuesday, 17 June 2014 at 20:25:52 UTC, Walter Bright wrote:
> You have a lot of good thoughts on this issue.
>
> You have specific problems in mind but do not identify them other than in vague terms. I guarantee that I am really, really bad at mindreading.
>
> Instead, I would strongly prefer that you:
>
> 1. write bugzilla issues for the problems that you identify
>
> 2. connect those bugzilla issues regarding @safe with the 'safe' keyword
>
> 3. construct specific proposals for how to fix these issues. The proposals don't actually have to be pull requests, just descriptions on the bugzilla pages for how to fix.
>
> 4. write pull requests for the documentation
>
>
> Even doing just one of 1..4 would be most appreciated. Merely asserting that @safe is broken/buggy/etc. will not result in progress.

I don't think he will. He's been explaining you for the past
several posts that this process is fundamentally broken, and
won't achieve the goals of @safe.

Please have a step back and look at the broader issue here.

On 6/17/2014 1:30 PM, deadalnix wrote:
> I don't think he will. He's been explaining you for the past
> several posts that this process is fundamentally broken, and
> won't achieve the goals of @safe.
>
> Please have a step back and look at the broader issue here.

What plan of action do you propose?

On Tuesday, 17 June 2014 at 20:50:01 UTC, Walter Bright wrote:
> On 6/17/2014 1:30 PM, deadalnix wrote:
>> I don't think he will. He's been explaining you for the past
>> several posts that this process is fundamentally broken, and
>> won't achieve the goals of @safe.
>>
>> Please have a step back and look at the broader issue here.
>
> What plan of action do you propose?

Make everything @system unless they are proven @safe instead of
trying to plug the holes in the condom one by one and hope you
don't end up with 20 years of child support.

On Monday, 16 June 2014 at 13:12:33 UTC, Timon Gehr wrote:
> My point was that no implementation of @safe whatsoever can make it _equivalent_ to memory safety (i.e. @safe will never single out precisely those programs that do not corrupt memory). It will always only approximate memory safety. This is not a bug, it's just a fact.

Out of curiosity, what is "memory safety" defined to be? Does it include running out of stack?

It should not be a problem if @safe rejects some memory safe programs. It still verifies that they are memory safe if they pass (as opposed to "if and only if"). You can verify subsets even if you cannot define two crisp set that discriminate between all possible programs.

Btw, Rice's theorem is based on the halting problem for TMs… so it suffers from the same issues as everything else in theoretical CS when it comes to practical situations. Whether generated IR contains unsafe instructions is trivially decidable. Since you can define an IR in a way that discriminate between unsafe/safe instructions you can also decide that the safe subset is verifiable memory safe.

> to agree on. In this case this is witnessed by the fact that you do not seem to want to ban undefined behaviour from @safe code which I can't agree with.

Then just define the undefined behaviour as yielding the integer result of a unspecified black box function of the input. Integer overflow should yield the same value for the same operands on all ALUs. I don't understand how this relates to memory safety?

On 6/17/2014 1:59 PM, deadalnix wrote:
> On Tuesday, 17 June 2014 at 20:50:01 UTC, Walter Bright wrote:
>> What plan of action do you propose?
> Make everything @system

The default is @system.


> unless they are proven @safe instead of
> trying to plug the holes in the condom one by one and hope you
> don't end up with 20 years of child support.

Instead of asserting there are unspecified holes, please identify them with bugzilla issues and connect them with the 'safe' keyword. Doing otherwise is useless and nothing will come of it.

Arguing that the spec is wrong without identifying specifically what is wrong and how it should be corrected is useless and nothing will come of it.


There are many people (particularly Kenji) who spend many hours combing bugzilla looking for things to fix. Issues not in bugzilla do not get fixed. Nonspecific complaints on the n.g. are ineffective in garnering improvement.

On 6/17/2014 2:50 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> Out of curiosity, what is "memory safety" defined to be?

http://en.wikipedia.org/wiki/Memory_safety


> Does it include running out of stack?

Depends. If the stack has protection against stack overflow, then it is memory safe. If not, it is not memory safe. A guard page is an example of the former, but D's fibers suffer from the latter.


> Then just define the undefined behaviour as yielding the integer result of a
> unspecified black box function of the input. Integer overflow should yield the
> same value for the same operands on all ALUs. I don't understand how this
> relates to memory safety?

Exactly - offer an improved wording rather than just throwing up hands.