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

Steven Schveighoffer schveiguy at gmail.com
Wed Apr 8 16:40:01 UTC 2020


On 4/8/20 11:56 AM, 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.
> 

I was referring to the other one ;)

But we are talking about prototypes not functions. If the function is 
implemented in D and @safe, should you be required to mark the prototype 
@trusted? If so, what benefit does that provide?

I don't think the benefit is worth the cost of annoyance -- it ends up 
the same either way.

I just thought of another way to fix this whole mess (even Walter's 
@safe by default for extern(C)).

I don't want to post it deep inside this thread, so I'll move it to the top.

-Steve


More information about the Digitalmars-d mailing list