Shouldn't safety be the default.

[ryuukk_]

On Tuesday, 26 December 2023 at 12:00:13 UTC, Sebastiaan Koppe 
wrote:
> On Tuesday, 26 December 2023 at 11:32:15 UTC, ryuukk_ wrote:
>> https://dlang.org/spec/function.html#safe-functions
>>
>>
>> -No casting from a pointer type to any type with pointers 
>> other than void*.
>> -No casting from any non-pointer type to a pointer type.
>> -No pointer arithmetic (including pointer indexing).
>> -Cannot access __gshared variables.
>> -No inline assembler.
>>
>> I hope this never becomes the default
>
> I very much hope it does. It is a lot more economical.
>
> 9 out of 10 projects only need the features you mentioned 
> sparingly. It is less effort to mark those place `@trusted` 
> than the situation we are in now, where you need to sprinkle 
> `@safe` almost everywhere.
>
> Another way to look at is that the features you mentioned are 
> almost always used exclusively in low level code that best sits 
> behind an abstraction. If trusted is the default you need to 
> mark anything using it `@safe`, but if safe is the default you 
> only need to mark a few reusable low level pieces of code 
> `@trusted`.


I understand, you got a point, it makes the ecosystem better, so 
i'm probably wrong here

But i personally don't use any of these attribute in my code 
bases, they are pure annoyances, most of the time

Will it solve problems like these?

https://github.com/dlang/dub/issues/2600

https://forum.dlang.org/thread/mjmufdnrcexliatzgkwh@forum.dlang.org


I'd rather see time spent working on getting features that help 
people's code compile faster (dub doubled their compile time by 
starting to use std.sumtype) instead of making more of them no 
longer compile because they do not comply with dmd @christmas 
tree decoration edition

Let's put it that way, if most of my code consist of low level 
bits, why should i mark everything @unsafe? I view unsafe as a 
feature, not as a bug

I hope it'll be toggleable with a compiler flag