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

[Steven Schveighoffer]

On 4/8/20 2:57 PM, Timon Gehr wrote:
> On 08.04.20 17:56, Jonathan Marler wrote:
>> 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.
>>>
>>
>> Which Jonathan?  I'm on the side that if the compiler can verify it, 
>> it should be @safe.  The extern'ness of a function seems to be 
>> orthogonal as to whether it can be verified.  Having a function body 
>> seems to be the primary criteria.
>>
> 
> To be very clear, Steven says the following is desirable to allow as a 
> possibility:
> 
> ---
> module a;
> 
> extern(C) corrupt_memory()@system{
>      // ...
> }
> ---
> ---
> module b;
> extern(C) corrupt_memory()@safe;
> 
> void main()@safe{
>      corrupt_memory();
> }
> ---
> 
> A "prototype" is a function declaration without a function body.
> 
> Related: https://www.theregister.co.uk/2016/02/04/underhand_c_2015/

To be clear, Timon says the following EQUIVALENT situation is desirable 
to allow as a possibility, and somehow this is different than the above:

extern(C) void corrupt_memory() @trusted; // go ahead, trust this 
function named corrupt_memory.

Simply because the unseen function is marked @trusted (when it is really 
@system). In other words, the function author made zero guarantees about 
memory safety, and the prototype author just trusts him blindly.

And really, what I'm saying is that I want:

---
module a;
extern(C) void perfectly_safe @safe {
  // ...
}
---
---
module b;
extern(C) void perfectly_safe() @safe;
---

To be possible.

If we can't have that then you have to lie (say it's @trusted when it's 
actually mechanically checked).

You have to have the first (very very unlikely) case allowed in order to 
have the second case allowed. Disallowing one disallows the other.

Since the situation with @trusted requirements isn't any safer (I'd 
argue it's less safe since it dilutes the meaning of @trusted), I'd say 
don't put up red tape that doesn't help.

-Steve