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

[aliak]

On Wednesday, 8 April 2020 at 13:58:12 UTC, Steven Schveighoffer 
wrote:
> On 4/8/20 9:35 AM, aliak wrote:
>> On Wednesday, 8 April 2020 at 13:09:33 UTC, Steven 
>> Schveighoffer wrote:
>>> On 4/7/20 10:01 PM, Timon Gehr wrote:
>>>> [...]
>>> [...]
>> 
>> It really feels like you and Timon are talking past each other 
>> based on mixing up extern(C) declarations and extern(C) 
>> definitions?
>
> No, I think we both understand that difference. I actually 
> understand the point of view of Timon and Jonathan and agree 
> with that point of view, I just think the restriction isn't 
> helpful, and is just going to cause busywork for no true 
> benefit.

Ok 👍My bad then.

>
>> 
>> You can't mechanically check an extern(C) function declaration 
>> with no source code. And @trusted on a mechanically checked 
>> extern(C) function definition doesn't help anyone.
>
> If you have an extern(C) function that is mechanically checked 
> @safe, should you have to mark the prototype @trusted? This is 
> the question we are discussing.

Ah, then yeah, as mentioned above, I'm in your boat; if it's 
mechanically checked then there's no need to mark it @trusted, 
that'd just be a waste of time in the hunt for memory corruption.

>
> My opinion is that requiring a marking of @trusted doesn't make 
> anything safer or more correct. If the function all of a sudden 
> becomes @system (truly @system, and not semantically safe), 
> then the @trusted is still a lie.
>
> The result is just going to be people ignoring @trusted C 
> prototypes beyond the prototype definition itself, so it makes 
> @trusted less of a red flag than it should be.
>
> 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.

>
> If you see:
>
> @trusted extern(C) void copy(ubyte[] dest, ubyte[] src)
>
> Then you are going to go check it, see that it's really @safe 
> in the implementation, and start ignoring such prototypes as 
> flags. Maybe you comment on it so next time you don't waste 
> time going to check that one:

Yes, if I go to that definition and see that the body is @safe 
then I'll be annoyed. If that's a prototype to a function defined 
in a C library then it should not be allowed to be marked @safe.

>
> // really @safe in implementation
> @trusted extern(C) void copy(ubyte[] dest, ubyte[] src)
>
> Now, if it all of a sudden changes to @system, your @trusted 
> tag is still ignored, just like it was marked @safe. That is my 
> point. It doesn't change what is interpreted by a reviewer to 
> require @trusted, it just adds busywork to shut up the compiler.
>
> In the end, the difference between @safe and @trusted on an 
> extern(C) function prototype is documentation. functionally, 
> they are equivalent.
>
> -Steve