On Monday, 11 July 2016 at 18:00:20 UTC, Steven Schveighoffer wrote:
> On 7/11/16 1:50 PM, deadalnix wrote:
>> On Friday, 8 July 2016 at 19:26:59 UTC, Andrei Alexandrescu wrote:
>>> On 07/08/2016 02:42 PM, deadalnix wrote:
>>>> It is meaningless because sometime, you have A and B that are both safe
>>>> on their own, but doing both is unsafe. In which case A or B need to be
>>>> banned, but nothing allows to know which one. This isn't a bug, this is
>>>> a failure to have a principled approach to safety.
>>>
>>> What would be a good example? Is there a bug report for it?
>>>
>>
>> For instance:
>>
>> @safe
>> int foo(int *iPtr) {
>>     return *iPtr;
>> }
>>
>> @safe
>> int bar(int[] iSlice) {
>>     return foo(iSlice.ptr);
>> }
>>
>> foo assume that creating an invalid pointer is not safe, while bar
>> assume that .ptr is safe as it doesn't access memory. If the slice's
>> size is 0, that is not safe.
>
> That was reported and being worked on:
>
> https://github.com/dlang/dmd/pull/5860
>
> -Steve

Alright, but keep in mind that is an example, not the actual problem I'm talking about. There are many reasonable way to make the example above safe: disallow dereferencing pointers from unknown source, do a bound check on .ptr, disallow .ptr altogether and much more.

The root problem is that "@safe guarantee memory safety and if it doesn't it is a bug" provides no information as to what is the bug here and no actionable items as to how to fix it, or even as to what needs fixing.

On 7/11/2016 11:47 AM, deadalnix wrote:
> As you can see the behavior of each component here is fairly reasonable.
> However, the end result may not be.

As was mentioned elsewhere, integers getting indeterminate values only results in memory corruption if the language has an unsafe memory model.

The solution is something like this:

https://github.com/dlang/dlang.org/pull/1420

On 7/11/2016 10:50 AM, deadalnix wrote:
> foo assume that creating an invalid pointer is not safe, while bar
> assume that .ptr is safe as it doesn't access memory. If the slice's
> size is 0, that is not safe.

There's a PR to fix this:

https://github.com/dlang/dmd/pull/5860

On 7/11/2016 11:57 AM, deadalnix wrote:
> Alright, but keep in mind that is an example, not the actual problem I'm
> talking about. There are many reasonable way to make the example above
> safe: disallow dereferencing pointers from unknown source,

Once you're in @safe code, the assumption is that pointers are valid. Unknown sources are marked @trusted, where the programmer takes responsibility to ensure they are valid.


> do a bound check on .ptr, disallow .ptr altogether and much more.

The PR disallows .ptr in @safe code. The @safe alternative is &a[0] which implies a bounds check.


> The root problem is that "@safe guarantee memory safety and if it
> doesn't it is a bug" provides no information as to what is the bug here
> and no actionable items as to how to fix it, or even as to what needs
> fixing.

It's kind of a meaningless criticism. Any piece of code has a bug if it doesn't meet the specification, and there's no way to verify it meets the specification short of proofs, and if anyone wants to work on proofs I'm all for it.

In the meantime, please post all holes found to bugzilla and tag them with the 'safe' keyword.

On 7/10/2016 10:07 PM, Ola Fosheim Grøstad wrote:
>> Face it, your argument is destroyed :-)
> Of course not.

Trying to reparse and reframe your answers isn't going to help. I know all those rhetorical tricks <g>.

I wrote:

> All useful computer languages are unprincipled and complex due to a number of factors: [...]

to which you replied:

> not true

But there are no examples of such a language that doesn't fail at one or more of the factors, Scheme included. Not Prolog either, a singularly useless, obscure and failed language. You could come up with lists of ever more obscure languages, but that just adds to the destruction of your argument.

The fact that other languages like C++ are adopting feature after feature from D proves that there's a lot of dazz in D!

On Monday, 11 July 2016 at 21:52:36 UTC, Walter Bright wrote:
>> The root problem is that "@safe guarantee memory safety and if it
>> doesn't it is a bug" provides no information as to what is the bug here
>> and no actionable items as to how to fix it, or even as to what needs
>> fixing.
>
> It's kind of a meaningless criticism. Any piece of code has a bug if it doesn't meet the specification, and there's no way to verify it meets the specification short of proofs, and if anyone wants to work on proofs I'm all for it.
>
> In the meantime, please post all holes found to bugzilla and tag them with the 'safe' keyword.

You know, there is a saying: "When the wise point at the moon, the idiot look at the finger". I can't force you to look at the moon, I can only point at it.

On Monday, 11 July 2016 at 22:09:11 UTC, Walter Bright wrote:
> On 7/10/2016 10:07 PM, Ola Fosheim Grøstad wrote:
[Snip stuff about Scheme]

Scheme is a really nice, elegant language that's fun to hack with, but at the end of the day, if people were writing Nginx, or the Windows kernel, or HFT systems in Scheme, you can bet programmers would be pushing pretty hard for special exceptions and hooks and stuff for better performance or lower-level access, and eventually you'd end up with another C.

Walter said "all programming languages", but he's obviously referring to the programming market D is in.

On Tuesday, 12 July 2016 at 00:34:12 UTC, sarn wrote:
> On Monday, 11 July 2016 at 22:09:11 UTC, Walter Bright wrote:
>> On 7/10/2016 10:07 PM, Ola Fosheim Grøstad wrote:
> [Snip stuff about Scheme]
>
> Scheme is a really nice, elegant language that's fun to hack with, but at the end of the day, if people were writing Nginx, or the Windows kernel, or HFT systems in Scheme, you can bet programmers would be pushing pretty hard for special exceptions and hooks and stuff for better performance or lower-level access, and eventually you'd end up with another C.
>
> Walter said "all programming languages", but he's obviously referring to the programming market D is in.

This is a false dichotomy. Nobody says there should be no inconsistencies. Sometime, it is just necessary because of other concerns. But it is a cost, and, like all costs, must pay for itself.

Most of these do not pay for themselves in D.

On 7/11/2016 5:15 PM, deadalnix wrote:
> On Monday, 11 July 2016 at 21:52:36 UTC, Walter Bright wrote:
>>> The root problem is that "@safe guarantee memory safety and if it
>>> doesn't it is a bug" provides no information as to what is the bug here
>>> and no actionable items as to how to fix it, or even as to what needs
>>> fixing.
>>
>> It's kind of a meaningless criticism. Any piece of code has a bug if
>> it doesn't meet the specification, and there's no way to verify it
>> meets the specification short of proofs, and if anyone wants to work
>> on proofs I'm all for it.
>>
>> In the meantime, please post all holes found to bugzilla and tag them
>> with the 'safe' keyword.
>
> You know, there is a saying: "When the wise point at the moon, the idiot
> look at the finger". I can't force you to look at the moon, I can only
> point at it.

I don't see anything actionable in your comment.

On 7/11/2016 5:34 PM, sarn wrote:
> Walter said "all programming languages", but he's obviously referring to
> the programming market D is in.

I said "all USEFUL programming languages", thereby excluding toys, research projects, etc.

Of course, "useful" is a slippery concept, but a good proxy is having widespread adoption.

There are good reasons why Detroit's "concept cars" never survived intact into production. And why the windscreen on an airliner is flat instead of curved like the rest of the exterior.