Vision for the D language - stabilizing complexity?

[deadalnix via Digitalmars-d]

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.