Vision for the D language - stabilizing complexity?

[deadalnix via Digitalmars-d]

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.

This is one such case where each of this operation is safe 
granted some preconditions, but violate each other's 
preconditions so using both is unsafe.

>> The position is inconsistent because the dictatorship refuses 
>> to
>> compromise on mutually exclusive goals. For instance, @safe is 
>> defined
>> as ensuring memory safety. But not against undefined behaviors 
>> (in fact
>> Walter promote the use of UB in various situations, for 
>> instance when it
>> comes to shared). You CANNOT have undefined behavior that are 
>> defined as
>> being memory safe.
>
> I agree with that. What would be a good example? Where is the 
> reference to Walter's promotion of UB in @safe code?
>

I don't have a specific reference to point to right now. However, 
there have been several event of "@safe guarantee memory safety, 
it doesn't protect against X" while X is undefined behavior most 
of the time.