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

[Bruce Carneal]

On Monday, 6 April 2020 at 12:35:20 UTC, Steven Schveighoffer 
wrote:
> On 4/5/20 10:43 PM, 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.
>
> Is this really your argument? Do we need Scott Meyers to 
> explain such "esoteric" compiler errors like:
>
> Error: cannot call @system function memcpy from @safe function 
> main.
>
> I think this is not an hour-long talk, but a 10-second talk: "C 
> functions aren't checked by the D compiler, so they are @system 
> by default." Done.
>
> I think possibly those folks are going to be much more 
> vulnerable to the existing rules surrounding @trusted that many 
> of the core D developers can't seem to get right.
>
> @system by default extern(C) functions are literally the most 
> understandable and correct part of the whole D 
> @safe/@system/@trusted system. And you want to remove that. 
> Please reconsider.
>

Even though the formal review period is over I'd like to leave a 
response to an earlier post from Walter.  I've tagged it on here 
since it picks up on Steve's thoughts on the topic, which I agree 
with, and because a direct response in the Feedback Thread was, 
understandably, deleted.

For context, this is an excerpt from a post that Walter made in 
the Feedback Thread for DIP 1028 wherein he argues *against* 
@system by default for extern declarations.  Interspersed are my 
thoughts.

[snip]
>
> 1. it's a special case inconsistency, which has its own costs 
> and confusion.

C is not a safe language.  Defaulting C externs to @safe, as you 
propose, would be confusing.

>
> 2. the compiler cannot verify any extern declarations as being 
> safe, even D
> ones. It's always going to be up to the user to annotate them 
> correctly.

@safe should mean safe, as in machine checkable.  My position is 
that if it can't be machine checked, it shouldn't be considered 
@safe.

>
> 3. the extern(C) specifies an ABI, it doesn't say anything 
> about how the
> function is implemented, or even which language it is 
> implemented in. A pretty
> big chunk of the dmd implementation (80-90%?) is extern(C++)

Exactly, "it doesn't say anything..." so the default should be 
@system.

I'm not sure what you're trying to say in the second part. Is it 
that we should default to @safe because your code is 
safe-by-programmer-assertion and there's a lot of it?

>
> 4. it's trivial to mark a block of C function declarations with 
> @system and
> trivial to audit it. I've done it already to a bunch of 
> druntime headers

As you and others have noted, safety by convention doesn't scale.

>
> 5. D's separate compilation model relies on extern declarations 
> where source is
> not available and safety cannot be machine checked. It's 
> inherent
>

Yes.  Absent tooling upgrades, the super-safety conscious have 
whole program compilation and @trusted reviews to work with

> 6. We're just talking about the default. The whole point of 
> @safe being the
> default is that it is far and away the most common case, even 
> for C functions.

@safe doesn't work as a probability.  It aspires to certainty. 
('aspires' because could be bugs in the checker, or holes in the 
spec or, ...)

>
> 7. A function having different attributes depending on whether 
> or not a body is
> present is surprising behavior

Not surprising to me.  It just reflects the ability/inability of 
the compiler to check safety.

>
> 8. annotating "extern(C) void free(void*);" as @safe doesn't 
> make it safe, either, again relying on the user

Relying on the user to overcome bad defaults isn't going to work. 
  If it did you'd not need the @safe by default DIP.

> [snip]

As many others before me, I urge you to change direction 
regarding extern defaults.  Barring that I hope Atila will step 
in for the team to prevent an own goal.