On 1/3/2020 5:43 AM, Manu wrote:
> FWIW, I'm not emotional about this, but it seems like a really good
> opportunity to change @system to @unsafe, since @system appears almost
> nowhere in existing code (because is default).
> 'system' is a weird name for 'unsafe'. I've had lots of colleagues
> tell me they think it doesn't make sense... and I agree. It's a silly
> name, and defies the industries established terminology for no reason.
> We have exactly one opportunity to correct this, and this is it.

Andrei and I talked about this for a while before coming up with 'system'. We both felt that calling it 'unsafe' had undeserved negative connotations.

On Friday, 3 January 2020 at 05:57:09 UTC, Jesse Phillips 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
>>
>
> I think the DIP should specify the depreciation plan. Currently it only mentions it would be available through --preview (is it not expect to go further?

Another thought to depreciation, the compiler could deprecated system functions which aren't marked @system.

This depreciation would ignore all method calls. This basically means functions utilizing unsafe language features must declare that use in the signature.

The next part I'll need to think on is if there is a way to build out the @trusted annotations.

On 1/3/2020 1:24 PM, mipri wrote:
> [...]

I was going to write a reply, then read yours. Mine would be redundant.

On 1/3/2020 2:13 PM, Steven Schveighoffer wrote:
>> - it doesn't seem like Community input is wanted in any way, it's all "there is no choice"
> 
> There is no choice in that D must support safety. But I'm certain that if there were a very compelling reason not to make it the default, this would not be accepted. This IS the community feedback.

I've gotten a fair amount of feedback over the years "why isn't @safe the default" and having it not be the default implies D isn't serious about memory safety. I'm worn out suggesting that annotating with @safe is not a problem.

Delaying making @safe the default any longer is a serious strategic mistake.

On 1/3/2020 7:23 AM, Steven Schveighoffer wrote:
> Some sticky points:
> 
> 1. Currenty the compiler can "give up" on attribute inference, and therefore leaves functions as @system. What happens when @safe is the default? I would recommend that they should be inferred @safe, but this might be a code-breaking in some cases.

They'll be inferred @safe.

> 2. I'll echo here what other have said, because it's REALLY important: do NOT recommend slapping @trusted on anything. It's a very very bad idea, and destroys the whole concept of @safe. Rather, put @system on functions that have to be @system.

Yeah, that's a good idea.

On 1/3/2020 10:41 AM, Steven Schveighoffer wrote:
> Add to rationale:
> 
> The vast majority of non-template code written is @safe, but not marked as such. This means many projects cannot enable safe because their dependencies were not marked that way. This will correct that for all those dependencies.

Sounds good.

> Same can be said about pure and nothrow.

Unfortunately, not much code tends to be pure without expending much effort. Pure would be a poor default.

Nothrow is likely to become the default in the future. Please, start a new thread for discussion of that.

On 1/3/2020 2:37 PM, monkyyy wrote:
> I strongly oppose such a move.

Just add:

  @system:

to the top of your modules and you should be good to go for most cases.

On Friday, 3 January 2020 at 22:36:17 UTC, Alex wrote:
> [...]
> Not sure, if this fits here. But if I add ´´´@safe:´´´ at the beginning of the module, the library https://code.dlang.org/packages/vebtree does not compile any more.

you can't just slap `@safe:` on because all the libraries and stuff you depend on which wasn't marked @safe is still gonna stay @system and thus disallow your calls. Instead you need to use the compiler with the @safe by default PR.

I have done this for all dub packages now so everyone can review what this change actually does to their packages:

https://i.webfreak.org/safe-test/index.html

It seems that your vebtree package compiles fine, however that is not to say for the rest of dub. Currently a lot of issues are caused by phobos' std.bitmanip.bitfields. So a lot of these errors are certainly fixable, but currently it doesn't look good in terms of support. (Tested using phobos v2.089.1-198-gbb8ba28bf)

On Saturday, 4 January 2020 at 10:22:34 UTC, WebFreak001 wrote:
> On Friday, 3 January 2020 at 22:36:17 UTC, Alex wrote:
> I have done this for all dub packages now so everyone can review what this change actually does to their packages:
>
> https://i.webfreak.org/safe-test/index.html

Thank you!

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

Yes, please! All the way.

Thanks, Walter