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

[aliak]

On Monday, 6 April 2020 at 12:19:10 UTC, Steven Schveighoffer 
wrote:
> On 4/5/20 9:28 PM, Jonathan M Davis wrote:
> [snip]
>
> I'm not disagreeing with any of this. Technically, @safe 
> doesn't make sense on a C prototype.
>
> But practically, preventing it doesn't buy us anything 
> important. If you have a @safe extern(C) function (implemented 
> in D), and it switches to @system, searching for @trusted to 
> find its prototypes isn't the way to do it, you search for the 
> function name. And technically, the @safe marking is correct, 
> if the function is being checked.

It does make sense for a extern(C) D-defined function indeed. I 
think when it comes to an extern(C) function declaration that's 
linked to a C function, in that case @safe doesn't really make 
sense since the body cannot be verified - which is what i believe 
is meant.


>
> There are a lot of rules in D which are technically sound, but 
> result in pain and suffering in actual usage.
>
> e.g:
>
> static if(someBool)
>    return x;
> return y; // error statement not reachable
>
> inout int[] arr;
> writeln(arr); // OK
> writeln(arr.filter!(a => a %5 == 0)); // Error: only parameters 
> or stack based variables can be inout

I'm not sure those are technically sound. Maybe more incomplete 
implementations of the features?

>
> I don't want to add to this list.
>
> -Steve