@safe by default

[Atila Neves]

On Friday, 31 May 2024 at 13:06:16 UTC, Paul Backus wrote:
> On Thursday, 30 May 2024 at 18:35:36 UTC, Atila Neves wrote:
>> https://github.com/atilaneves/DIPs/blob/safe-by-default/safe-by-default.md
>>
>> Destroy!
>
> I agree completely that "having [@safe] be opt-in makes it hard 
> to use in practice" and that "defaults matter". However, I 
> think that implementing [Universal Function Attribute 
> Inference][1] would be a better way to address the shortcomings 
> of the current defaults.

It might be; it's something Walter and I have discussed before, 
and the reason that didn't go forward is due to the potential 
compile-time performance penalties. If it's doable in a fast way 
it would kill two birds with one stone, for sure.

> In ["Thoughts on Backward Compatibility"][2], I tried to figure 
> out why some breaking changes succeed and others fail. The 
> conclusion I came to was that breaking changes are most 
> successful when:
>
> 1. Migration is easy, or
> 2. The change serves a goal that has strong buy-in from users
>
> While there is a vocal minority in the D community who strongly 
> support @safe (a group in which I include myself), **I do not 
> believe that @safe has strong buy-in from D programmers as a 
> whole.** In other words, this proposal cannot satisfy condition 
> (2). It follows that, if we would like it to succeed, it *must* 
> satisfy condition (1).
>
> Sadly, I do not think migration to `-preview=safedefault` will 
> be particularly easy. By the DIP's own admission, it "will 
> likely break a lot of code". Even if editions allow us to mix 
> pre-migration and post-migration code in the same project, the 
> burden of migrating to `-preview=safedefault` will likely hurt 
> the adoption of new editions, and cause projects that would 
> otherwise upgrade to get "stuck" in the @system-by-default 
> edition.
> (It is also conceivable that new projects started by D 
> programmers who don't care about @safe will choose the old, 
> @system-by-default edition specifically to avoid the hassle of 
> adding explicit @system attributes to their code.)

I was going to write that I don't understand why anyone would 
want @system-by-default until I realised that calling legacy 
code, including dub packages, might be a pain. Hmm.

> Universal inference avoids these problems. In most cases, it 
> requires zero manual intervention to migrate existing code 
> (that is, it Just Works™). The only major obstacle it faces is 
> build performance when using separate compilation, and this 
> obstacle can be overcome with toolchain improvements.

I'm all for not having to write attributes the compiler can infer 
itself and having them "only" show up in .di files. As long as 
build speeds aren't affected, since it's too slow as it is for 
me. Do I like writing `@safe @nogc pure nothrow scope const`? No, 
but that's what I have to do right now.