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

[Jonathan Marler]

On Monday, 6 April 2020 at 02:43:51 UTC, Walter Bright wrote:
> On 4/5/2020 12:22 PM, Timon Gehr wrote:
>> I really doubt that. It's a simple rule. The version that is 
>> easiest to implement is you simply disallow extern(C) 
>> functions without body to be marked @safe. It's a single `if` 
>> statement in an appropriate place.
>
> Famous last words.
>
> Just look at the swamp of misery from "simple" C rules, such as 
> their effect on C++ overloading. The quagmire got a lot worse 
> when C++ added type inference. I attended a Scott Meyers talk 
> that was a full hour long just on the weird special cases 
> forced on C++ due to those simple rules. Companies pay Scott a 
> boatload of cash for these lectures.
>
> I wouldn't be surprised if more than half of the bugs in 
> bugzilla are the result of an unexpected interaction between 
> simple exceptions to rules.
>
> I've been around this block a few thousand times. Remember, it 
> ain't just the compiler. The users don't remember these 
> exceptions. Every one of them makes the language harder to 
> learn and master.

I agree that every language needs to be very careful with complex 
rules.  But I don't see this as a complex rule, I would word it 
like this:

     treat "the code" inside "code blocks" as @safe unless 
explicitly marked as @system

Note that this would exclude function declarations themselves, as 
they are not "code", but instead, wrappers to executable code 
that comes from somewhere else and cannot be verified to be 
"@safe".  Whereas a function with a body (i.e. a code block) 
would be treated as @safe, namely, because the compiler can 
verify it is safe.

I think the rule is simple when you know the right way to define 
it.  I don't see any exceptions or "ifs", just a simple 
straightforward rule.


I would like to add however that I don't see you using this same 
"the rule is too complex" argument on DIP1032. Which would read 
something like this:

     function and delegate pointer types use the attributes that 
are listed, except when the type declarations themselves are 
function parameters or defined inside a function; in which case 
they would inherit all attribute from their contining function. 
(question: would nested functions also inherit attributes?).  
Although, if the type itself is defined outside the function and 
only an alias is used to declare a pointer inside the function 
then it will not inherit the attributes from the containing 
function

I also have a low confidence that covers all the complexity this 
rule would require, but that's what I came up with so far.  That 
rule seem much more complex to me, and the only benefit I see is 
saving some tokens on some function/delegate type declarations, 
which I don't see come up too often anyway.  From my end it looks 
like you aren't applying the same rules to every proposal, 
rather, you're selectively cherry-picking arguments for each 
individual one.