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

Jonathan Marler johnnymarler at gmail.com
Mon Apr 6 18:40:21 UTC 2020


On Monday, 6 April 2020 at 01:43:58 UTC, Timon Gehr wrote:
> On 06.04.20 02:09, Jonathan Marler wrote:
>> On Saturday, 4 April 2020 at 06:53:57 UTC, Walter Bright wrote:
>>> [....]
>>> Now, as to what to do. I spent a few minutes and added 
>>> `@system:` in to the C headers in druntime for windows, 
>>> posix, and linux. Done. I hope someone else will do it for 
>>> freebsd, etc., if not I'll go do that to.
>>>
>> 
>> The thought crossed my mind that this same reasoning could be 
>> applied as a counter-argument for this DIP:
>> 
>> ... So functions are not safe by default?
>> 
>> Now, as to what to do. I spent a few minutes and added
>> `@safe:` in to the source files in druntime for windows, posix,
>> and linux. Done. I hope someone else will do it for freebsd,
>> etc., if not I'll go do that to.
>> ...
>
> So you annotated all those extern(C) function prototypes as 
> @safe? :)
>

That paragraph wasn't something I was saying, I took what Walter 
said (see above) and replaced a couple words to show the argument 
he was using to say extern functions should be considered @safe 
by default could also be used to argue against the DIP itself.

A good way to test the merit of an argument is to apply it to 
multiple scenarios.  For example, you could say "I like apples 
because they are red."  To test if that's the real reason you 
like apples you can try the same argument with other scenarios.  
You could try "I like tomatoes because they are red", but if you 
don't acutally like tomatoes, which are also red, then that means 
the "redness" of objects may not have much to do with why you 
like apples.  Redness may contribute to your "likeness" but there 
are probably more important factors.

In this situation Walter said (paraphrased) "If you want to to 
make your extern functions @system by default, put them in their 
own file and put "@system:" at the top".  But the whole point of 
this DIP is to change the default from @system to @safe, so the 
same argument he used would be an argument against his own DIP, 
"If you want to make your functions @safe by default, put them in 
their own file and put "@safe:" at the top".

This leads me to believe that he hasn't shared or identified the 
real reason he doesn't agree with what people are saying about 
defaulting to @system on unverifiable functions.  It's like he is 
saying "I like apples because they are red", and then turning 
around later and saying "I don't like tomatoes because they are 
red".  Either defaults matter or they don't, if they don't then 
you are saying your own DIP doesn't matter, if they do, then I 
wouldn't dismiss what people are saying about the default 
@safeness of unverifiable functions.


More information about the Digitalmars-d mailing list