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

[Mathias Lang]

On Thursday, 26 March 2020 at 10:55:44 UTC, Atila Neves wrote:
> On Wednesday, 25 March 2020 at 21:58:40 UTC, Jonathan Marler 
> wrote:
>> Has the benefit warranted the cost to manage these tags 
>> throughout your code?
>
> Yes. Especially since the cost is trivial.
>
>> Do we have any projects that are already using this behavior 
>> by putting "@safe:" at the top of every file?  Does anyone 
>> have any pointers to projects that have done this?
>
> All my projects that aren't called reggae. The only reason for 
> that exception is that it's ancient and I didn't know any 
> better then.
>
> I don't know how we've managed, but we've utterly failed at 
> marketing @safe to the community. Writing @safe code is easy 
> unless you're doing manual memory management or trying to 
> abstract it with a library. *Especially* with DIP1000.

There's a huge difference between correctly using `@safe` and 
having things compile.

I have *never* seen non-trivial library that manage to do the 
former without imposing strong requirements on the user. Let me 
repeat that: I haven't seen a *single* non-trivial library out 
there that does it correctly. It either forces user code to be 
`@safe`, or bypasses `@safe`ty checks completely.

And since exceptional claims calls for exceptional proof, I 
wanted to check whether or not your libraries would be any 
different. It took me less than 5 minutes to find this: 
https://github.com/atilaneves/unit-threaded/issues/176

We didn't fail to market `@safe`. We failed to provide a 
construct that allows users to write libraries that take 
attributes (`@safe`, `nothrow`, `@nogc`, same fight) into account 
without incredible amounts of boilerplate.

Take any library that accepts a delegate: Either one has to 
restrict what the delegate can do, or make a certain attribute 
un-enforceable. There's no way to write an interface that 
concisely expresses that its `@safe`ty, `@nogc`-ness or 
`nothrow`-ness depends on the user-provided delegate, unless you 
template absolutely everything, which is not a viable (and 
sometimes, not possible) solution.

We need something similar to `inout` for attributes. Or at the 
very least, a way to express this dependency. Only then will 
changing the default be a remotely viable possibility, in my 
opinion. At the moment, all this is doing is ignoring the problem 
and pushing the complexity from one demographic to the other.