This is the discussion thread for the Final Review of DIP 1028, "Make @safe the Default":

https://github.com/dlang/DIPs/blob/5afe088809bed47e45e14c9a90d7e78910ac4054/DIPs/DIP1028.md

The review period will end at 11:59 PM ET on April 8, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.

Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.

However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

And my blog post on the difference between the Discussion and Feedback threads:

https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/

Please stay on topic here. I will delete posts that are completely off-topic.

On Wednesday, 25 March 2020 at 07:02:32 UTC, Mike Parker wrote:

> However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:

The Feeback thread is here:

https://forum.dlang.org/post/wkdpnzarkbtqryighzpx@forum.dlang.org

#DIP1028

I have an alternative to @safe by default that may be a better option for the near future.

Given a headconst tied to life time (similar to a borrowed pointer) we can then change the default of that function to be @safe.

This can be slowly expanded to include raw pointers declarations that are never assigned to as well.

It doesn't get us 100% of the way there, but it does allow those who care about memory safety about 80% of the way there and gives us more time to adapt code.

Thoughts welcome.

In response to Walter's response to ag*, I would say that there is a fatal problem with automatically allowing extern(C) function prototypes (and really, anything that does not mangle @safe) to be default @safe.

The reason is simple -- the change is silent and automatically marks everything @safe that has not been checked.

I would argue that if the compiler is going to make things @safe by default, then things that are not marked and are not @safe should not compile AT ALL COSTS. Otherwise the value of @safe is completely lost.

The DIP should be rejected IMO unless all functions with no mechanism to mangle @safe into the name (e.g. extern(C), extern(C++), etc) that have no implementation are either:

a) required to be marked, or
b) default @system.

Everything else in the DIP is possibly annoying to deal with but at least doesn't silently destroy the meaning of @safe.

I will note that I support the notion of @safe by default. I would be in favor of the DIP as long as this fatal flaw is not included.

-Steve

On Wednesday, 25 March 2020 at 14:10:18 UTC, Steven Schveighoffer wrote:

> Everything else in the DIP is possibly annoying to deal with but at least doesn't silently destroy the meaning of @safe.

To be perfectly honest, I can't imagine D being a sensible option for someone wanting to work heavily with C code if you have to add pointless annotations and constantly deal with compiler errors. It's not a matter of annoyance, it's simply impractical to add that kind of overhead, particularly if someone else is involved. If you're using C, you're well aware that it's not going to be safe. Rust was designed for *writing* safe code, not for wrapping C libraries, which is maybe the main use of D right now.

On Wednesday, 25 March 2020 at 07:02:32 UTC, Mike Parker wrote:
> This is the discussion thread for the Final Review of DIP 1028, "Make @safe the Default":
>
> https://github.com/dlang/DIPs/blob/5afe088809bed47e45e14c9a90d7e78910ac4054/DIPs/DIP1028.md
>
> The review period will end at 11:59 PM ET on April 8, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.
>
> Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.
>
> However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:
>
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> And my blog post on the difference between the Discussion and Feedback threads:
>
> https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/
>
> Please stay on topic here. I will delete posts that are completely off-topic.

Never thought D would actually do this.  I'm on the fence as to whether this is a good idea.  However, with all the D code I've written that would break from this I'd prefer not to do this; that is, unless the people who want this feature are willing to go through hundreds of thousands of lines of D code that I've written and fix it :)  Looks like I've got I've got 79 repos on github with D in them (although some are just forks and some are private).

https://github.com/marler8997?tab=repositories&q=&type=&language=d

On Wed, Mar 25, 2020 at 05:34:11PM +0000, bachmeier via Digitalmars-d wrote:
> On Wednesday, 25 March 2020 at 14:10:18 UTC, Steven Schveighoffer wrote:
> 
> > Everything else in the DIP is possibly annoying to deal with but at least doesn't silently destroy the meaning of @safe.
> 
> To be perfectly honest, I can't imagine D being a sensible option for someone wanting to work heavily with C code if you have to add pointless annotations and constantly deal with compiler errors. It's not a matter of annoyance, it's simply impractical to add that kind of overhead, particularly if someone else is involved. If you're using C, you're well aware that it's not going to be safe.
[...]

If you're interfacing D code with C code, your main() is probably
already @system anyway, so you might as well just stick @system: at the
top of your extern(C) declarations and call it a day.


T

-- 
The two rules of success: 1. Don't tell everything you know. -- YHL

On 3/25/20 1:34 PM, bachmeier wrote:
> On Wednesday, 25 March 2020 at 14:10:18 UTC, Steven Schveighoffer wrote:
> 
>> Everything else in the DIP is possibly annoying to deal with but at least doesn't silently destroy the meaning of @safe.
> 
> To be perfectly honest, I can't imagine D being a sensible option for someone wanting to work heavily with C code if you have to add pointless annotations and constantly deal with compiler errors. It's not a matter of annoyance, it's simply impractical to add that kind of overhead, particularly if someone else is involved. If you're using C, you're well aware that it's not going to be safe. Rust was designed for *writing* safe code, not for wrapping C libraries, which is maybe the main use of D right now.

This is overblown. Adding @system: at the top of a c library header is not hard.

Tools which generate headers for C libraries (e.g. dpp) can automatically do the right thing.

-Steve

On 3/25/20 1:53 PM, Jonathan Marler wrote:

> that is, unless the people who want this feature are willing to go through hundreds of thousands of lines of D code that I've written and fix it :)  Looks like I've got I've got 79 repos on github with D in them (although some are just forks and some are private).
> 
> https://github.com/marler8997?tab=repositories&q=&type=&language=d

I'm not willing, but I bet dfix will be.

-Steve

On Wednesday, March 25, 2020 12:04:33 PM MDT Steven Schveighoffer via Digitalmars-d wrote:
> On 3/25/20 1:34 PM, bachmeier wrote:
> > On Wednesday, 25 March 2020 at 14:10:18 UTC, Steven Schveighoffer wrote:
> >> Everything else in the DIP is possibly annoying to deal with but at least doesn't silently destroy the meaning of @safe.
> >
> > To be perfectly honest, I can't imagine D being a sensible option for someone wanting to work heavily with C code if you have to add pointless annotations and constantly deal with compiler errors. It's not a matter of annoyance, it's simply impractical to add that kind of overhead, particularly if someone else is involved. If you're using C, you're well aware that it's not going to be safe. Rust was designed for *writing* safe code, not for wrapping C libraries, which is maybe the main use of D right now.
>
> This is overblown. Adding @system: at the top of a c library header is not hard.
>
> Tools which generate headers for C libraries (e.g. dpp) can
> automatically do the right thing.

Not only that, but if _any_ function is automatically marked as @safe when the compiler can't verify that it is, and no programmer has verified that it is and marked it with @trusted, then @safe is borderline pointless and useless, because it's not actually guaranteeing memory safety. We have enough of a problem with programmers incorrectly using @trusted without the compiler doing it. @safe needs to provide actual compiler guarantees, or it just provides a false sense of security. extern(C) functions ultimately exist in the call stack of every D program (even if most of them are buried in D code rather than being used directly by the program), and to have those treated as @system with no verification basically throws @safe's guarantees out the window.

I agree with Walter's assertion that the DIP applies to extern(C) functions unless it says otherwise, but that being the case, the DIP needs to be fixed so that it does not apply to extern(C) functions, or it will do _far_ more damage than good.

- Jonathan M Davis