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

[Arine]

On Thursday, 26 March 2020 at 15:02:15 UTC, Steven Schveighoffer 
wrote:
> On 3/26/20 10:40 AM, jmh530 wrote:
>> On Thursday, 26 March 2020 at 14:12:24 UTC, Steven 
>> Schveighoffer wrote:
>>> [snip]
>>> And in actuality, most D code is @safe, so for most D code 
>>> out there, this is not going to be a huge problem. You will 
>>> have to mark few things. Wrappers/bindings for C libraries 
>>> are going to be an exception, and that's just the pain we 
>>> have to deal with. Either use trusted markings to make 
>>> everything safe (after verification), or just punt to the 
>>> user.
>>>
>> 
>> There is a lot of functionality that depends on C libraries. 
>> For instance, every or almost every function in lubeck calls 
>> at least one C function. If someone comes to D from python and 
>> wants to replace something from numpy/scipy with a lubeck 
>> equivalent, they will need to start slapping @trusted or 
>> @system on everything. That means they will need to understand 
>> the safety system and why stuff like that matters. For some 
>> people, that may be a big enough burden that they just throw 
>> up their hands and keep using python.
>> 
>
> 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 will be my goto solution as D lacks the means many other 
languages have to maintain compatibility. In C++ I can choose the 
standard I want to use, and avoid any removed or changed features 
if they affect me. Same goes for C#, Rust, and basically every 
other established language.

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

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

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.

D's solution to the problem: "this is the best practice now". 
That doesn't stop already written code from being broken.