On Thursday, 2 January 2020 at 10:41:20 UTC, Basile B. 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.
>
> 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.

actually dont take in account the final note. It would obviously not work for agregates (struct, class) only for module level free funcs. Sorry for that.

On Thursday, 2 January 2020 at 12:23:54 UTC, ag0aep6g wrote:

> 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.

What compiler do you use? I always get error messages when I try to call @system functions from @safe code.

> And legacy code should be treated as @system, not as @trusted.

Perfectly working legacy code should by default stop compiling?

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

The rationale seems a bit lacking.

On 02.01.20 13:34, bachmeier wrote:
> On Thursday, 2 January 2020 at 12:23:54 UTC, ag0aep6g wrote:
[...]
> What compiler do you use? I always get error messages when I try to call @system functions from @safe code.


Why would you suddenly be calling @system functions from @safe code?

If all functions in your call chain are currently not marked, then you mark them all as @system for the DIP, and the code compiles just as it used to.

If the calling function is currently marked as @safe but the called function isn't, then the chain already doesn't compile.


>> And legacy code should be treated as @system, not as @trusted.
> 
> Perfectly working legacy code should by default stop compiling?


Yes. And if you want your working unsafe program back, you have to add lots of @system attributes.

You might oppose the DIP on the grounds that that's too much hassle for too little gain. That's a reasonable position.

Treating all legacy code as @trusted (when it was clearly @system before) would not be reasonable, in my opinion.

All that said, you *can* slap `@trusted:` onto your modules, of course. You really shouldn't, but you can.

On 02.01.20 10:47, 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 

There's this paragraph in the DIP: "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."

The last part there can be read as advice to D programmers on how to adjust their code. I'm afraid it will be interpreted as: "Just slap @trusted on your unsafe code." Which is terrible advice.

I suggest changing the part after the colon to something like: "annotate that code with @system."

I.e.:

1) Don't use "safe" without an @ sign. It's too fuzzy a word.
2) Don't recommend @trusted. It's not needed to get the code working again.

On Thursday, 2 January 2020 at 13:21:17 UTC, ag0aep6g wrote:
> Why would you suddenly be calling @system functions from @safe code?
>
> If all functions in your call chain are currently not marked, then you mark them all as @system for the DIP, and the code compiles just as it used to.
>
> If the calling function is currently marked as @safe but the called function isn't, then the chain already doesn't compile.
Yes! I fully support this DIP.
But at the same time, additionally @trusted as a function attribute should be removed and replaced by @trusted expressions. Because:

> Treating all legacy code as @trusted (when it was clearly @system before) would not be reasonable, in my opinion.

This should NOT be possible!
We would lose a lot of safety if even a few library developers do that. @trusted should be restricted to as few code as possible, at best only to the line of code where it is really necessary to make a function @safe.

On Thursday, 2 January 2020 at 12:34:05 UTC, bachmeier wrote:
> [snip]
>
> What compiler do you use? I always get error messages when I try to call @system functions from @safe code.
> [snip]

Nothing prevents you from going function by function to verify if you can make things @trusted or @safe. It would be a big time commitment for legacy code, of course.

Or, you can just make main @system as well.

I think what you are really trying to say is more about interacting between legacy code that was @system by default and new code that is @safe by default. But @system code can call @safe code without any problem. So maybe just write the new code as you please, but then make main @system? There is value in this point. I think most people think it will be quite disruptive.

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 [...]
> someone writes a tool that adds @system to every function that is not annotated @safe or @trusted (or already @system) (probably not that hard).

Yes, yes!
But this tool should not slap @system on every function, but only on those that don't compile with the new default - the rest was already @safe but the proper annotation was missing, so this is the benefit we get. Don't waste it!

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 dip, doesn't describe how to make the destroy function for classes safe, as the class deconstructors don't inherent the attributes from the parent class. This issue is major blocking point on why I don't use D for serious software development for gaming development.(It also the reason why you can't call the destroy function for classes in nogc and nothrow context either)

-Alex

On 02.01.20 14:47, Dominikus Dittes Scherkl wrote:
> But at the same time, additionally @trusted as a function attribute should be removed and replaced by @trusted expressions. Because:
[...]
> @trusted should be restricted to as few code as possible, at best only to the line of code where it is really necessary to make a function @safe.

One step at a time. As it is, the DIP may be disruptive but it's simple. Improvements to @trusted can go in another DIP.

Applying @trusted to as little code as possible sounds good, but it's often done incorrectly with the effect that @safe is weakened.

Here's a quick example from a GitHub search on Phobos [1]:

    auto p = (() @trusted => fakePureMmap(null, bytes,
        PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0))();
    /* ... stuff ... */
    return (() @trusted => p[0 .. bytes])();

Strictly speaking, that second lambda cannot be @trusted. Its safety relies on `p` and `bytes` being compatible. But an unlucky contributor might accidentally set `p = new byte;` or `bytes = 1024^^3;` in "stuff". Those mistakes would pass as @safe, but they would likely lead to memory corruption. The corruption would happen after an edit that only touched @safe code. That's exactly what D's safety system is supposed to prevent.

But I agree that applying @trusted to the function signature is ugly and misleading.

For a caller, there is zero difference between these two functions:

    void f() @trusted { /* ... stuff ... */ }
    void f() @safe { () @trusted { /* ... the same stuff ... */ } (); }

Having @trusted visible in the function signature just gives people wrong ideas about what it means.


[1] https://github.com/dlang/phobos/blob/5e6fe2f9c8f72f4c3b0497dc363fc61d823ff489/std/experimental/allocator/mmap_allocator.d#L38-L45