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

[Bruce Carneal]

On Saturday, 11 April 2020 at 07:30:26 UTC, Walter Bright wrote:
> [snip]
>
> On the other hand,
>
> 1. it's a special case inconsistency, which has its own costs 
> and confusion.
>

More confusing than promoting the notion that C is safe? My 
personal confusion over your stance on this is at 11.

> 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.
>

Yes, anything that is not machine checked is more than a little 
suspect.

> 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++)
>

I have no reason to doubt 3), I just don't understand how it 
relates to safety.

> 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 stated, with my full concurrence, coding 
conventions don'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

Yep.  Absent tool augmentation the super-safety conscious are 
left with whole program compilation and @trusted reviews.

>
> 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 is only useful if it excludes probabilistic behavior so 
"far and away the most common case ..." is, for me, a strong 
argument against your position.

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

To me it simply reflects the reality that its not machine 
checkable.

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

When you "rely on the user" you want the defaults to point to 
safety, not the other way round.

>
> 9. what do we do with "nothrow" by default? ...
I have no strong use cases where this matters so I'll leave it to 
others.

I'm hoping that you either change direction or that Atila steps 
in to block the apparent own goal.