DIP 1028---Make @safe the Default---Community Review Round 1

[Arine]

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.