Discussion Thread: DIP 1028--Make @safe the Default--Final Review

Manu turkeyman at gmail.com
Thu Mar 26 07:29:51 UTC 2020


On Thu, Mar 26, 2020 at 5:17 PM Manu <turkeyman at gmail.com> wrote:

> On Thu, Mar 26, 2020 at 12:15 AM Steven Schveighoffer via Digitalmars-d <
> digitalmars-d at puremagic.com> wrote:
>
>> In response to Walter's response to ag*, I would say that there is a
>> fatal problem with automatically allowing extern(C) function prototypes
>> (and really, anything that does not mangle @safe) to be default @safe.
>>
>> The reason is simple -- the change is silent and automatically marks
>> everything @safe that has not been checked.
>>
>> I would argue that if the compiler is going to make things @safe by
>> default, then things that are not marked and are not @safe should not
>> compile AT ALL COSTS. Otherwise the value of @safe is completely lost.
>>
>> The DIP should be rejected IMO unless all functions with no mechanism to
>> mangle @safe into the name (e.g. extern(C), extern(C++), etc) that have
>> no implementation are either:
>>
>> a) required to be marked, or
>> b) default @system.
>>
>> Everything else in the DIP is possibly annoying to deal with but at
>> least doesn't silently destroy the meaning of @safe.
>>
>> I will note that I support the notion of @safe by default. I would be in
>> favor of the DIP as long as this fatal flaw is not included.
>>
>> -Steve
>>
>
> I'm really on board with this. My feeling though is that it should be b;
> extern(Language) should be @system by default, except maybe extern(Rust),
> which nobody has ever asked for.
>

There's also the matter that with this DIP we REALLY need @trusted
expressions or scopes. It's inappropriate that you need to tag an entire
function when you just want to make one unsafe call and the few lines of
surrounding context assert any safety requirements.

I also think that the names make little sense in a @safe-by-default world,
and really there should only be @unsafe. It's not necessary to have @system
AND @trusted.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20200326/78734ced/attachment.htm>


More information about the Digitalmars-d mailing list