On Thursday, 2 January 2020 at 09:47:48 UTC, Mike Parker wrote:

[snip]

> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> *Please stay on topic!*
>
> Thanks in advance to all who participate.

I get the impression that most of the negative feedback here falls into the following categories:

1) This will break too much code
2) Crappy code is ok, don't burden users to make their code @safe
3) It's too much effort to convert existing code to @safe

Having basically *only* written @safe code for years now (although sometimes misusing @trusted), here are my opinions on the categories I came up with:

1)
As with every other recent DIP, the change will be gated with `-preview` so initially it will be opt-in. No breakages will happen overnight.

Also as with every other recent DIP, after that initial period it will become opt-out with `-revert`. At most, and only sometime in the future, breakages can be easily avoided by adding one flag to the compiler invocation command. I wish it weren't true, but I suspect that this particular revert flag will last for quite a while.


2) and 3)
Most D code is @safe. Nearly all of it is. Unless you're taking addresses of locals (which can be made @safe by using DIP1000 and scope), doing pointer arithmetic, or slicing pointers, nearly all instances of @system code left will be casts. I would be very surprised if many changes have to be made, *especially* if the default becomes @safe since most of the problems I face are in dependencies.

This is why changing the default is important: most code is @safe anyway but we're not getting the benefits because it's more effort to annotate than not, so most people don't bother.

"But we're already safer than C++" is analogous to "but we already compile faster than C++". They're both low bars to set, and the compiler can never be "too fast". Eliminating more bugs at compile-time is one of our goals. This DIP helps us get closer to the ideal.

On Saturday, 4 January 2020 at 06:43:16 UTC, Walter Bright wrote:
> 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.

I see this pattern is this topic: "just add @system and everything will be fine".

So isn't this will create a trend where when developer is bothered by the compiler then they will just do this and in the end "safety" will never be achieve?

Matheus.

On 04/01/2020 11:42 PM, Atila Neves wrote:
> 
> I get the impression that most of the negative feedback here falls into the following categories:
> 
> 1) This will break too much code
> 2) Crappy code is ok, don't burden users to make their code @safe
> 3) It's too much effort to convert existing code to @safe

There is a solution to all three of the categories that you have described that would be of major benefit to D over all. And it has not been posted on this thread yet.

We defer this going live till D3.

This way we can do a big push for all the changes that have the potential for changing workflows and limitations of existing code while ensuring a massive announcement when we have got everything ready to be used.

There would still be the preview switch, but it won't be made the default by itself. It would be grouped into a new switch ``-preview=d3`` and when we are ready we can turn that on by default instead.

Lets tell a story about how to do memory safety, that gives us headlines. Lets not do stuff that causes people pain that they are not fully on board with.

On Saturday, 4 January 2020 at 10:22:34 UTC, WebFreak001 wrote:
> 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)

Thank you very much!

On 1/4/20 5:22 AM, WebFreak001 wrote:
> 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)

Awesome! I'll look into the bitmanip problems.

Can you do us a favor and sort by package name?

-Steve

On Saturday, 4 January 2020 at 10:22:34 UTC, WebFreak001 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
>

I unfortunately have to question some of the results in that list. I have a single, simple package called "sml" in dub and it actually compiles (without @safe by default). This contradicts what your list is stating.

On Saturday, 4 January 2020 at 14:46:40 UTC, Gregor Mückl wrote:
> On Saturday, 4 January 2020 at 10:22:34 UTC, WebFreak001 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
>>
>
> I unfortunately have to question some of the results in that list. I have a single, simple package called "sml" in dub and it actually compiles (without @safe by default). This contradicts what your list is stating.

Please everyone, take this discussion to a new thread and keep this one focused on review of DIP 1028.

Thanks!

On Friday, 3 January 2020 at 22:37:24 UTC, monkyyy wrote:
> I strongly oppose such a move.
>
> I am in all likelyhood going to mark every line of code with @trusted
What a crappy idea.
Why should that be necessary?

> You will be increasing verbosity, and promoting lying code;
No. You just need to add @system, and that only if you really did use unsafe features in your code. Which in fact is not that often, even in very low level code.

> Theres needs a non-verbose, non-lying way to opt-out, and probably shouldn't be opt-in in the first place.
There will be a compiler-option to opt out (after the years where there is a compiler-option to opt-in). So no need to get upset (yet).
And after those years I'm pretty sure you will have a new view on that - when you're the only one still needing @system on more than a hand full of functions

> I would suggest module scope default behaviors.
I personally don't like that, but it is there.
I just hope this will vanish over the time as I think it's crappy style.

On Friday, 3 January 2020 at 22:59:53 UTC, Walter Bright wrote:
> On 1/3/2020 5:57 AM, Arine wrote:
>> Then this would be better served as an opt in feature.
>
> It will be opt-in for a time, that's why it will be enabled with -preview=safedefault

No one is going to really use that, they'll just wait til it's required. I'm already dreading some of the deprecations that there already are. It'll break my code and the fixes for it will make it worse than it was. At which point when it becomes an error I'll probably just stick with an older version, or build my own variant with a patch to turn it off.

>> This is going to be a big breaking change, and if you are going to do the same thing with `nothrow`, that's way too much breakage for very little benefit just to follow a trend.
>
> There are compelling reasons for nothrow by default. I suggest deferring this discussion until the DIP is put forward for review.
>
>
>> Especially if steps aren't going to be taken to ensure it is easy to maintain backwards compatibility. As someone else mentions
>> 
>> @system:
>> 
>> does not give the same behavior and will still break code.
>
> It's still easy to deal with.

It's more work. It doesn't matter if it is easy. I worked for a company where one of the developers REALLLY hated warnings. So much so that he changed all the variable and class names because the C# compiler was giving warnings that the style didn't match the standard. Part of the problem was the serialization used reflection so changing the variable/class names was a breaking change for this API. This API interfaced with our software and it was the only way to interface with our software. The only way to get data into our software to use was through this API. So now for our customers to use our software they had to wait for an updated version with our partners. The thing is, the partners were telling their customers to not upgrade to the newest version of our software. It was a mess for our customers and the companies we partnered with. He didn't listen to reason, having no warnings was more important to him, and another companies problem was their problem.

Sure changing the names is easy, but it's boring tedious grunt work that's a waste of time for very little to no benefit.

>> There's probably already an issue filed for it. It comes up often. I don't have the time right now to search through tens of thousands of unmanaged issues for you. I already gave an example in my preview post.
>
> Spending time guessing and speculating on what it might be does a disservice to those who do spend the time filing issues, on which I and others do spend effort to address.
>
> > tens of thousands of unmanaged issues
>
> This is why there are bugzilla keywords for categorizing issues, like `safe` for all safety related issues:
>
> https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=safe&keywords_type=allwords&list_id=229608&query_format=advanced

That doesn't mean those categorizations are used. No body is ensuring they are set. Anyone can set them, they can set them incorrectly, no one checks for duplicates, no one is making sure that an issue is even relevant or accomplish-able. There's issues that are 5+ years old, some of them with no comments. Some of them with comments promising to get it fixed. I don't know how you can point to a list of categories and just because they exist, claim that the issue list isn't an unmanaged mess.

On Friday, 3 January 2020 at 22:59:53 UTC, Walter Bright wrote:
>> This is going to be a big breaking change, and if you are going to do the same thing with `nothrow`, that's way too much breakage for very little benefit just to follow a trend.
>
> There are compelling reasons for nothrow by default. I suggest deferring this discussion until the DIP is put forward for review.

An expression comes to mind, "death by a thousand cuts". If you are only going to look at each DIP on it's own, without also taking into consideration other DIPs, then you aren't going to realize just how much breakage the accumulation of all the DIPs is actually causing. There's been a lot of DIPs that cause a bunch of breaking changes recently. They are all small, but it's all starting to add up. And the breakage is starting to outweigh the benefits that they bring. To me personally for my projects, they don't really bring any benefit, but they still break my code.