Jump to page: 1 225  
Page
Thread overview
DIP 1028---Make @safe the Default---Community Review Round 1
Jan 02, 2020
Mike Parker
Jan 02, 2020
Mike Parker
Jan 02, 2020
WebFreak001
Jan 02, 2020
Basile B.
Jan 02, 2020
Basile B.
Jan 02, 2020
bachmeier
Jan 02, 2020
bachmeier
Jan 02, 2020
ag0aep6g
Jan 02, 2020
bachmeier
Jan 02, 2020
ag0aep6g
Jan 02, 2020
ag0aep6g
Jan 02, 2020
jmh530
Jan 02, 2020
bachmeier
Jan 02, 2020
jmh530
Jan 02, 2020
bachmeier
Jan 02, 2020
jmh530
Jan 02, 2020
bachmeier
Jan 02, 2020
jmh530
Jan 02, 2020
jmh530
Jan 02, 2020
jmh530
Jan 02, 2020
mipri
Jan 02, 2020
jmh530
Jan 03, 2020
Walter Bright
Jan 03, 2020
jmh530
Jan 02, 2020
Les De Ridder
Jan 02, 2020
ag0aep6g
Jan 02, 2020
12345swordy
Jan 02, 2020
Guillaume Piolat
Jan 02, 2020
JN
Jan 03, 2020
Adam D. Ruppe
Jan 03, 2020
H. S. Teoh
Jan 03, 2020
Mathias Lang
Jan 03, 2020
Walter Bright
Jan 03, 2020
Walter Bright
Jan 03, 2020
Adam D. Ruppe
Jan 03, 2020
Atila Neves
Jan 03, 2020
Walter Bright
Jan 03, 2020
Guillaume Piolat
Jan 03, 2020
Atila Neves
Jan 03, 2020
Walter Bright
Jan 03, 2020
Adam D. Ruppe
Jan 03, 2020
Walter Bright
Jan 03, 2020
12345swordy
Jan 03, 2020
Walter Bright
Jan 03, 2020
Walter Bright
Jan 03, 2020
12345swordy
Jan 03, 2020
Walter Bright
Jan 03, 2020
bachmeier
Jan 03, 2020
Walter Bright
Jan 02, 2020
Arine
Jan 02, 2020
H. S. Teoh
Jan 03, 2020
Eugene Wissner
Jan 03, 2020
Walter Bright
Jan 03, 2020
Timon Gehr
Jan 03, 2020
Walter Bright
Jan 03, 2020
Arine
Jan 03, 2020
Walter Bright
Jan 03, 2020
Arine
Jan 03, 2020
Walter Bright
Jan 03, 2020
Johan
Jan 04, 2020
Walter Bright
Jan 04, 2020
Arine
Jan 04, 2020
Arine
Jan 04, 2020
IGotD-
Jan 02, 2020
IGotD-
Jan 02, 2020
Walter Bright
Jan 03, 2020
Jesse Phillips
Jan 03, 2020
Jesse Phillips
Jan 04, 2020
Jesse Phillips
Jan 08, 2020
Jesse Phillips
Jan 03, 2020
Jesse Phillips
Jan 03, 2020
Walter Bright
Jan 03, 2020
Mathias Lang
Jan 03, 2020
Walter Bright
Jan 03, 2020
Walter Bright
Jan 07, 2020
Mathias Lang
Jan 08, 2020
Walter Bright
Jan 03, 2020
Jacob Carlborg
Jan 03, 2020
Walter Bright
Jan 03, 2020
Dennis
Jan 03, 2020
Manu
Jan 03, 2020
David Gileadi
Jan 03, 2020
Dennis Cote
Jan 04, 2020
Walter Bright
Jan 06, 2020
Manu
Jan 07, 2020
Max Samukha
Jan 07, 2020
Paulo Pinto
Jan 07, 2020
Paulo Pinto
Jan 07, 2020
Max Samukha
Jan 07, 2020
Paulo Pinto
Jan 07, 2020
Manu
Jan 07, 2020
Max Samukha
Jan 07, 2020
JN
Jan 07, 2020
Max Samukha
Jan 07, 2020
NaN
Jan 07, 2020
Arine
Jan 08, 2020
Guillaume Piolat
Jan 08, 2020
Walter Bright
Jan 08, 2020
Les De Ridder
Jan 08, 2020
Arine
Jan 08, 2020
Manu
Jan 08, 2020
Mathias Lang
Jan 08, 2020
Timon Gehr
Jan 09, 2020
Manu
Jan 09, 2020
Walter Bright
Jan 09, 2020
Manu
Jan 15, 2020
Walter Bright
Jan 09, 2020
Johannes Pfau
Jan 09, 2020
Arine
Jan 09, 2020
Timon Gehr
Jan 09, 2020
IGotD-
Jan 09, 2020
Timon Gehr
Jan 09, 2020
H. S. Teoh
Jan 09, 2020
Timon Gehr
Jan 09, 2020
ag0aep6g
Jan 09, 2020
ag0aep6g
Jan 09, 2020
Arine
Jan 09, 2020
Timon Gehr
Jan 09, 2020
ag0aep6g
Jan 09, 2020
Paolo Invernizzi
Jan 15, 2020
Walter Bright
Jan 15, 2020
Timon Gehr
Jan 15, 2020
Walter Bright
Jan 09, 2020
H. S. Teoh
Jan 09, 2020
Walter Bright
Jan 09, 2020
Arine
Jan 09, 2020
Manu
Jan 09, 2020
H. S. Teoh
Jan 09, 2020
Basile B.
Jan 09, 2020
Manu
Jan 09, 2020
Arine
Jan 09, 2020
Timon Gehr
Jan 08, 2020
Manu
Jan 09, 2020
Walter Bright
Jan 09, 2020
Arine
Jan 04, 2020
Walter Bright
Jan 03, 2020
Meta
Jan 03, 2020
monkyyy
Jan 04, 2020
Walter Bright
Jan 04, 2020
matheus
Jan 06, 2020
Walter Bright
Jan 04, 2020
Walter Bright
Jan 03, 2020
Guillaume Piolat
Jan 03, 2020
mipri
Jan 03, 2020
Guillaume Piolat
Jan 03, 2020
mipri
Jan 04, 2020
Walter Bright
Jan 03, 2020
Guillaume Piolat
Jan 03, 2020
Alex
Jan 04, 2020
WebFreak001
Jan 04, 2020
Atila Neves
Jan 04, 2020
Alex
Jan 04, 2020
Gregor Mückl
Jan 04, 2020
Mike Parker
Jan 04, 2020
Walter Bright
Jan 05, 2020
Walter Bright
Jan 04, 2020
Walter Bright
Jan 08, 2020
Mathias Lang
Jan 08, 2020
WebFreak001
Jan 03, 2020
H. S. Teoh
Jan 03, 2020
Guillaume Piolat
Jan 04, 2020
Walter Bright
Jan 04, 2020
Per Nordlöw
Jan 04, 2020
Atila Neves
Jan 04, 2020
rikki cattermole
Jan 04, 2020
Walter Bright
Jan 05, 2020
rikki cattermole
Jan 05, 2020
Jesse Phillips
Jan 04, 2020
Walter Bright
Jan 04, 2020
Walter Bright
Jan 04, 2020
Gregor Mückl
Jan 04, 2020
Walter Bright
Jan 04, 2020
Sebastiaan Koppe
Jan 04, 2020
jxel
Jan 04, 2020
Sebastiaan Koppe
Jan 04, 2020
Adam D. Ruppe
Jan 04, 2020
Walter Bright
Jan 04, 2020
jxel
Jan 05, 2020
H. S. Teoh
Jan 05, 2020
jxel
Jan 05, 2020
H. S. Teoh
Jan 05, 2020
jxel
Jan 06, 2020
Walter Bright
Jan 06, 2020
jxel
Jan 05, 2020
Timon Gehr
Jan 06, 2020
Walter Bright
Jan 05, 2020
NaN
Jan 06, 2020
James Blachly
Jan 06, 2020
Paulo Pinto
Jan 05, 2020
Jon Degenhardt
Jan 05, 2020
Walter Bright
Jan 12, 2020
berni44
Jan 12, 2020
Ogi
Jan 13, 2020
Arine
Jan 13, 2020
bachmeier
Jan 13, 2020
bachmeier
Jan 13, 2020
Adam D. Ruppe
Jan 14, 2020
rikki cattermole
Jan 14, 2020
Adam D. Ruppe
Jan 14, 2020
jmh530
Jan 15, 2020
Timon Gehr
Jan 14, 2020
Arine
Jan 15, 2020
Timon Gehr
Jan 14, 2020
Jesse Phillips
Jan 14, 2020
MoonlightSentinel
Jan 14, 2020
Jesse Phillips
Jan 15, 2020
Walter Bright
Jan 15, 2020
jmh530
Jan 15, 2020
Walter Bright
Jan 17, 2020
Mike Parker
January 02, 2020
This is the feedback thread for the first round of Community Review for DIP 1028, "Make @safe the Default":

https://github.com/dlang/DIPs/blob/1b705f8d4faa095d6d9e3a1b81d6cfa6d688554b/DIPs/DIP1028.md

All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on January 16, or when I make a post declaring it complete.

At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.

Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:

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

*Please stay on topic!*

Thanks in advance to all who participate.
January 02, 2020
On Thursday, 2 January 2020 at 09:47:48 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1028, "Make @safe the Default":

And to make it searchable: #DIP1028
January 02, 2020
On Thursday, 2 January 2020 at 09:47:48 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1028, "Make @safe the Default":
>
> https://github.com/dlang/DIPs/blob/1b705f8d4faa095d6d9e3a1b81d6cfa6d688554b/DIPs/DIP1028.md
>
> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on January 16, or when I make a post declaring it complete.
>
> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.
>
> Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:
>
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> *Please stay on topic!*
>
> Thanks in advance to all who participate.

This is a simple but really powerful change. I think most issues you would have with @safe right now would simply be gone as it's very often libraries which are not marked @safe causing trouble, rather than actually using unsafe code.

In my experience most code is written as safe code and only very rarely are the unsafe code features actually needed. Having aid by the compiler not accidentally using unsafe code will definitely help most users. Users writing a lot of @system code like for example those writing OS drivers (very niche) will have issues that relatively easily can be fixed by placing @system in the affected functions or add a @system: on top of the file (which will not work that well with the other code though)

As with all such changes there will be a lot of pain and silent breakage for those using __traits(compiles, {}) with something related with @safe/@system. I don't think deprecations are shown in it so the transition period will also not help with that. I think having a system to mitigate this issue is really important, but that's rather part of another DIP and shouldn't interfere so much with this DIP. With these 'compiles' checks for @safe/@system you most often call the function anyway, which will trigger the deprecation warnings so this is not that big of an issue in 98% of the cases.

To fix code it will be minimal changes, which could probably even be automated by suggestions from the IDE. :)

Overall I think the DIP is good as-is and will bring more positives than negatives to D.
January 02, 2020
On Thursday, 2 January 2020 at 09:47:48 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1028, "Make @safe the Default":
>
> https://github.com/dlang/DIPs/blob/1b705f8d4faa095d6d9e3a1b81d6cfa6d688554b/DIPs/DIP1028.md
>
> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on January 16, or when I make a post declaring it complete.
>
> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.
>
> Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:
>
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> *Please stay on topic!*
>
> Thanks in advance to all who participate.

While I don't disapprove I suggest a very long deprecation phase, based on

1. a compiler switch for let's say 1 year, allowing to test and prepare
2. after that, the real deprecation, following what the official rule for D deprecation imply, and concerning what is not annotated
3. after that, non annotated funcs will be @safe.
4. Maybe a compiler switch for backward compatibility should be added at the end. This could help in case someone use unmaintained libraries.

Based on this comment, I suggest to amend the DIP to add a **very detailed plan**, a schedule, for how things would append. This is not clear for now.

Finally a more technical remark is that maybe you should mention that annotating a whole module, after the module declaration, `@system:` makes the maintenance easy. For now the DIPS seems to suggest that all funcs should be annotated.
January 02, 2020
On Thursday, 2 January 2020 at 09:47:48 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1028, "Make @safe the Default":
>
> https://github.com/dlang/DIPs/blob/1b705f8d4faa095d6d9e3a1b81d6cfa6d688554b/DIPs/DIP1028.md
>
> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on January 16, or when I make a post declaring it complete.
>
> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.
>
> Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:
>
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> *Please stay on topic!*
>
> Thanks in advance to all who participate.

"This will likely break most code that has not already been annotated with @safe, @trusted, or @system. Fortunately, the solution is easy, although tedious: annotate functions that aren't safe with @trusted or @system."

Maybe I'm missing something, but the spec says

"Trusted functions are guaranteed to not exhibit any undefined behavior if called by a safe function. Furthermore, calls to trusted functions cannot lead to undefined behavior in @safe code that is executed afterwards. It is the responsibility of the programmer to ensure that these guarantees are upheld."

If I want to make my code compile, I'd be forced to declare a function @trusted *even if it shouldn't be*. In other words, if we go down this road, @trusted loses its meaning. If I mark it @system, that doesn't really help, because my code still isn't going to compile.

Perhaps someone can explain where I'm wrong. If I'm correct, then it would make more sense to declare at the top of a file that this is legacy code and thus treated as @trusted unless marked otherwise.
January 02, 2020
On Thursday, 2 January 2020 at 11:10:38 UTC, bachmeier wrote:
> On Thursday, 2 January 2020 at 09:47:48 UTC, Mike Parker wrote:
>> This is the feedback thread for the first round of Community Review for DIP 1028, "Make @safe the Default":
>>
>> https://github.com/dlang/DIPs/blob/1b705f8d4faa095d6d9e3a1b81d6cfa6d688554b/DIPs/DIP1028.md
>>
>> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on January 16, or when I make a post declaring it complete.
>>
>> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.
>>
>> Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:
>>
>> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>>
>> *Please stay on topic!*
>>
>> Thanks in advance to all who participate.
>
> "This will likely break most code that has not already been annotated with @safe, @trusted, or @system. Fortunately, the solution is easy, although tedious: annotate functions that aren't safe with @trusted or @system."
>
> Maybe I'm missing something, but the spec says
>
> "Trusted functions are guaranteed to not exhibit any undefined behavior if called by a safe function. Furthermore, calls to trusted functions cannot lead to undefined behavior in @safe code that is executed afterwards. It is the responsibility of the programmer to ensure that these guarantees are upheld."
>
> If I want to make my code compile, I'd be forced to declare a function @trusted *even if it shouldn't be*. In other words, if we go down this road, @trusted loses its meaning. If I mark it @system, that doesn't really help, because my code still isn't going to compile.
>
> Perhaps someone can explain where I'm wrong. If I'm correct, then it would make more sense to declare at the top of a file that this is legacy code and thus treated as @trusted unless marked otherwise.

I want to make this comment in a new reply since it's separate from the previous comment. I dislike this proposal because it's too large without a corresponding move to D 3.0. It won't just break existing code, but also existing tutorials and documentation. I strongly support the change. Just not in D 2.* since that will be too confusing for new/occasional users of the language.
January 02, 2020
On Thursday, 2 January 2020 at 09:47:48 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1028, "Make @safe the Default":
>

I believe this DIP should be not be accepted until 1) it is possible to write a @safe RC type, 2) someone writes a tool that adds @system to every function that is not annotated @safe or @trusted (or already @system) (probably not that hard).

January 02, 2020
On Thursday, 2 January 2020 at 11:19:52 UTC, jmh530 wrote:
> On Thursday, 2 January 2020 at 09:47:48 UTC, Mike Parker wrote:
>> This is the feedback thread for the first round of Community Review for DIP 1028, "Make @safe the Default":
>>
>
> I believe this DIP should be not be accepted until 1) it is possible to write a @safe RC type, 2) someone writes a tool that adds @system to every function that is not annotated @safe or @trusted (or already @system) (probably not that hard).

If a function is not annotated, why should it default to @system? That has a specific meaning that probably shouldn't apply to most code.
January 02, 2020
On Thursday, 2 January 2020 at 11:31:59 UTC, bachmeier wrote:
> [snip]
>> I believe this DIP should be not be accepted until 1) it is possible to write a @safe RC type, 2) someone writes a tool that adds @system to every function that is not annotated @safe or @trusted (or already @system) (probably not that hard).
>
> If a function is not annotated, why should it default to @system? That has a specific meaning that probably shouldn't apply to most code.

I'm thinking about the transition. (non-template) Functions are currently implicitly @system, but that will change to @safe. So there should be a way to easily transition from the old default to the new one. Not really different from what someone mentioned above with putting @system: at the top of the file.
January 02, 2020
On 02.01.20 12:10, bachmeier wrote:
> If I want to make my code compile, I'd be forced to declare a function @trusted *even if it shouldn't be*. In other words, if we go down this road, @trusted loses its meaning. If I mark it @system, that doesn't really help, because my code still isn't going to compile.

Yes, you shouldn't blindly slap @trusted on your non-@safe functions.

But you *can* blindly slap @system on them. Non-annotated functions are already @system by default; you're just making it explicit. Your code should compile the same as today.

> Perhaps someone can explain where I'm wrong. If I'm correct, then it would make more sense to declare at the top of a file that this is legacy code and thus treated as @trusted unless marked otherwise.

There's not really a way to do it for a whole file, but with `@system:` and `@system { ... }` the busywork might be tolerable. Though I would consider it better practice to mark each function individually.

And legacy code should be treated as @system, not as @trusted.
« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10 11