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

[aliak]

On Wednesday, 8 April 2020 at 17:01:29 UTC, Steven Schveighoffer 
wrote:
> On 4/8/20 11:52 AM, aliak wrote:
>>> If you see:
>>>
>>> @trusted extern(C) void memcpy(void *dest, void *src, size_t 
>>> size)
>>>
>>> Then this is obviously wrong, and should be @system. It 
>>> wouldn't be any different for a @safe marking.
>> 
>> Yes it would? If this was @safe I wouldn't need to check its 
>> usage sights because I'm supposed to trust that @safe can only 
>> be applied to functions that are mechanically checked. If it's 
>> @trusted then I know I need to check it's usage sights because 
>> it's not mechanically guaranteed to be a safe function.
>
> There may be something you are missing. You can mark e.g. 
> memcpy @safe, and the compiler is fine with it. It will still 
> link, and now be callable inside @safe code.

I was under the assumption we were talking about how to go 
forward from whatever the current status quo was.

Though, I did not know that was how it worked now because frankly 
I never tried marking an extern(C) function (declaration, not 
definition) as @safe - never even occurred to me.

If that's possible now then it should be fixed as I can't see how 
that's correct behaviour.

>
> The connection between the prototype and the implementation is 
> MANUALLY maintained for extern(C) code.
>
> So if you saw @safe here, you should not be satisfied with it, 
> as the marking is probably wrong, but will still compile. You 
> shouldn't say "well, it's marked @safe, so memcpy must be 
> @safe".
>
> This is the whole problem with extern(C) prototypes -- you are 
> allowed to lie without consequence.
>
> But in a lot of cases, D-implemented extern(C) code *is* @safe, 
> so it wouldn't be a lie.
>
> -Steve