Jump to page: 1 212  
Page
Thread overview
Discussion Thread: DIP 1028--Make @safe the Default--Final Review
Mar 25
bachmeier
5 days ago
Walter Bright
6 days ago
Kagamin
5 days ago
Walter Bright
6 days ago
Atila Neves
5 days ago
Mathias Lang
5 days ago
Walter Bright
5 days ago
Mathias Lang
5 days ago
Adam D. Ruppe
5 days ago
Atila Neves
4 days ago
Arine
6 days ago
bachmeier
6 days ago
Walter Bright
6 days ago
Walter Bright
6 days ago
Kagamin
6 days ago
Adam D. Ruppe
6 days ago
Adam D. Ruppe
5 days ago
Walter Bright
6 days ago
Atila Neves
6 days ago
12345swordy
5 days ago
Atila Neves
6 days ago
Kagamin
6 days ago
Kagamin
6 days ago
Adam D. Ruppe
5 days ago
Kagamin
5 days ago
Walter Bright
6 days ago
jmh530
6 days ago
jmh530
5 days ago
Walter Bright
1 day ago
Walter Bright
1 day ago
Arine
5 hours ago
Walter Bright
5 days ago
jmh530
4 days ago
Arine
4 days ago
Atila Neves
2 days ago
Arine
2 days ago
Atila Neves
2 days ago
Timon Gehr
Re: Sociomantic/Discord GC experience
5 hours ago
Walter Bright
5 hours ago
Walter Bright
1 day ago
Atila Neves
1 day ago
Arine
2 days ago
Meta
1 day ago
JN
1 day ago
Mike Parker
6 days ago
Arine
6 days ago
Arine
4 days ago
Jacob Carlborg
6 days ago
Walter Bright
6 days ago
Walter Bright
6 days ago
Jesse Phillips
6 days ago
Manu
6 days ago
Manu
6 days ago
Walter Bright
5 days ago
Mathias Lang
6 days ago
Walter Bright
6 days ago
Jonathan Marler
6 days ago
IGotD-
6 days ago
IGotD-
6 days ago
Atila Neves
6 days ago
ag0aep6g
6 days ago
H. S. Teoh
5 days ago
sarn
6 days ago
Walter Bright
6 days ago
Jonathan Marler
6 days ago
Walter Bright
6 days ago
Andrej Mitrovic
6 days ago
H. S. Teoh
6 days ago
Kagamin
5 days ago
aliak
March 25
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.
March 25
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
March 26
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.
March 25
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
March 25
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.
March 25
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
March 25
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
March 25
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
March 25
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
March 25
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



« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10 11