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