Discussion Thread: DIP 1028--Make @safe the Default--Final Review

Arine arine123445128843 at gmail.com
Thu Mar 26 23:31:06 UTC 2020


On Thursday, 26 March 2020 at 19:30:16 UTC, Steven Schveighoffer 
wrote:
> On 3/26/20 2:56 PM, Arine wrote:
>> On Thursday, 26 March 2020 at 15:02:15 UTC, Steven 
>> Schveighoffer wrote:
>>> Writing
>>>
>>> @system:
>>>
>>> At the top of your modules is not a big burden. If that 
>>> drives you away from the language, then I'm sorry to say that 
>>> you are missing out on the awesomeness of D, but I can't 
>>> really help you.
>> 
>> I can, just write
>> 
>> @trusted:
>
> This isn't a good idea. But yeah, you can do that at your own 
> peril (and anyone who uses your library). I'd highly recommend 
> using @system: instead.

There are problems with @system:, they are outlined in great 
detail in the first review thread (just as @safe: has the same 
issues). I don't really feel like repeating the same arguments 
over and over again just to have someone tell me to just use 
@system: again. You can search the previous thread. @trusted: 
will be the only true easiest solution. If you are writing 
@system it really doesn't matter to you either way. Those that 
suffer are the people that care about @safe, just as it is the 
people using @system now that will suffer if this DIP goes 
through without any kind of proper backwards compatibility 
measure set in place (like any good language has).

>> This will be my goto solution as D lacks the means many other 
>> languages have to maintain compatibility.
>
> The means are: use the correct markings. @system works now, and 
> will after this change.

They are correct for the *current* version of D. This DIP will 
break that. If I'm using a library and the author hasn't updated 
their library, it is now my burden to update their library as 
well. I have to maintain their library.

The problem isn't what works now. The problem is that there is 
going to be a change, that change is going to break code. That 
code will have to be updated to work after the change. There's no 
easy way to just have that code work again.

What you are basically telling people is that if they are using 
10 different libraries, that they should take on the 
responsibility of maintaining those libraries and update them to 
be compatible with this change. This is not **practical**.

You know what Rust does? There's a version indicator in cargo 
config files that specifies what version of Rust to use.

Let's say Rust decided to change the default to be "unsafe" in 
the next version of Rust. If you created a new project and used a 
library that still required the old version of Rust. You can 
still build and use that library like normal. How is this such a 
foreign concept that people are willing to argue tooth and nail 
against having backwards compatibility instead of breaking a 
large amount of code because a default is being change (don't 
forget about @nothrow; this is why DIPs shouldn't be looked at on 
their own and why most other languages create different 
versions/standards).

>>> How many people were driven away from windows development 
>>> because they had to deal with __stdcall? You just googled for 
>>> it (or whatever the hell was available at the time), said "oh 
>>> this is how you do it", and did it. It wasn't a problem, you 
>>> just did it.
>> 
>> You don't need to do that anymore, they changed it (for the 
>> better). It probably did drive people away. Especially when 
>> you deal with small issues consistently. They start piling up, 
>> and you can only deal with so many tiny issues (which D has 
>> many of; and will only grow with all the new changes coming 
>> forward).
>
> Meh, you just do it. Saying "why do I have to write @system 
> when I don't care about safety" is like saying "why do I have 
> to write void when I have no return value". Just do it, and 
> your code works. For those who don't care.

Why do I have to fix my code because of a change the compiler 
made with no easy solution to maintain backwards compatibility. 
Updating my code isn't an easy solution. That's the problem. 
Practicality is what is at stake. People don't have time to waste 
to keep their code simply compiling.

>>> This is only even a discussion because of the current 
>>> situation. If D started out this way, you would have no idea 
>>> there was even a problem here.
>> 
>> Right, because people don't want to have to keep updating 
>> their code or have it be broken. Other languages ensure 
>> backwards compatibility, and if they don't they provide a way 
>> to keep the code working without having to modify the code to 
>> work.
>
> I think the intention is to have an automated tool to mark 
> things that are currently @system as @system explicitly. I 
> would expect that feature in dfix, before this would become the 
> default.
>
> You are free to use other languages if you feel that way. IMO 
> this change is for the better, and provides a much healthier 
> default. Without it, most code is @safe-but-not-marked as that 
> is the default. The new default will allow more usage of @safe.

This isn't the only breaking change taking place. There are a 
large number of breaking changes happening. Yes this is only one 
DIP, and I'm sure someone will pop up saying "don't discuss other 
DIPs, this thread is only for DIPxxxx". That's the problem when 
there's only one "version" of D and DIPs are split apart without 
being able to look at the overall picture of what is happening.

I agree, it is probably for the better. The changes made in 
python 3 was for the better. Look at what they did for changes 
that were for the better. Did they break all code in existence? 
Or did they provide a means for people to keep their existing 
code working without a significant waste of resources to update 
it.

>> D's solution to the problem: "this is the best practice now". 
>> That doesn't stop already written code from being broken.
>
> Or again, switch to a "sensible" language like Rust or C# or 
> C++. Don't pick Swift though, they change stuff all the time, 
> it probably is going to die soon, I doubt anyone will put up 
> with that.
>
> -Steve

The way Apple operates, I wouldn't doubt Swift being killed off 
:). I see Walter and Apple having a lot in common, except that 
one is actually successful.




More information about the Digitalmars-d mailing list