On 17.06.20 16:37, Andrei Alexandrescu wrote:
> On 6/17/20 10:30 AM, jmh530 wrote:
>> Regardless, it means that @safe is not currently safe.
> 
> Affirmative. Clearly this is the problem. Opting into @system by means of an variable annotation that is NOT FLAGGED IF MISSING is not helping.
> 
> Making @system opt-in is completely backwards.

No, it is not.

It is a tool to write correct and efficient @trusted code. @trusted code has to ensure memory safety regardless of how @safe code behaves. The type system and @safe checks allow @trusted code to make assumptions about @safe code. Introducing specific features that restrict what @safe code can do is precisely the right way to go about it and it has been the way @trusted works from the start.

The goal of any modular analysis is to be able to at least assign blame to any problem that ends up cropping up anyway, this is true in particular for D's @safe/@system/@trusted and the blame always lies in @trusted functions. Without @system variables, @trusted functions always have to check that their invariants hold. This can range from expensive to completely intractable, in particular if the invariants are related to the state of memory allocators.

You are either misunderstanding @trusted or arguing in favor of completely redesigning D's safety system and thereby destroying what makes @trusted great. In that case we can just as well switch to the inferior Rust `unsafe` model with unclear assumptions and guarantees and get rid of @trusted entirely.

On 17.06.20 18:30, Andrei Alexandrescu wrote:
> 
> * The bool story seems like a problem with bool more than anything. It seems excessive to mark something as common and useful as bool as a @system type. The right solution is to fix bool.

That's what the DIP proposes. It does not make `bool` a @system type, it just explicitly makes it a type with _trap values_. I.e., @safe code cannot write arbitrary bit patterns into `bool` memory because some of them do not correspond to either `true` or `false`.

On 6/17/20 12:47 PM, Timon Gehr wrote:
> On 17.06.20 16:37, Andrei Alexandrescu wrote:
>> On 6/17/20 10:30 AM, jmh530 wrote:
>>> Regardless, it means that @safe is not currently safe.
>>
>> Affirmative. Clearly this is the problem. Opting into @system by means of an variable annotation that is NOT FLAGGED IF MISSING is not helping.
>>
>> Making @system opt-in is completely backwards.
> 
> No, it is not.

I was misunderstanding.