DIP 1028---Make @safe the Default---Community Review Round 1

H. S. Teoh hsteoh at quickfur.ath.cx
Fri Jan 3 07:40:14 UTC 2020


On Fri, Jan 03, 2020 at 01:46:20AM +0000, Adam D. Ruppe via Digitalmars-d wrote:
[...]
> I'm slightly in favor of this dip, I've said before that as it is, the
> annotations are more hassle than they are worth, but think the swapped
> defaults would push it slightly over the edge. (I kinda feel the same
> about pure, nothrow, etc but it does get murkier there, especially
> since there's no equivalent to @system and @trusted there!)
[...]

I'm for this DIP, but have reservations about the extent of code
breakage it's going to cause and how to mitigate that.

Just out of curiosity, I took one of my current projects this morning
and started putting @safe: on top of every file, just to see how far I
got.

I quickly ran into the issue that delegates are @system by default, so
I have to manually stick @safe onto every one of them, which is a
hassle, but I suppose wouldn't be a problem once @safe becomes default.
But it also leads to another issue: generic code can't reasonably just
throw @safe onto every delegate type, because sometimes you *want* to
support @system delegates.  There are various ways of mitigating this,
of course, but it involves a lot more code rewriting than I'd like to
have when this DIP takes effect.

Another issue is that taking the address of locals is verboten in @safe
code. It's generally found in self-contained code, but becomes a problem
across 3rd party library API boundaries: if an API requires a pointer
there's not much you can do about it without waiting for an upstream fix
(which will break API with older code). I suppose @trusted lambdas would
be a workaround, but it does greatly uglify otherwise already-working
code and again requires effort to rewrite/work around.

So we better have a good, practical implementation schedule before
merging this DIP.


T

-- 
Three out of two people have difficulties with fractions. -- Dirk Eddelbuettel


More information about the Digitalmars-d mailing list