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

[Guillaume Piolat]

On Friday, 3 January 2020 at 21:24:03 UTC, mipri wrote:
> Another result: instead of the status quo of "mark something
> @safe -> get explosion of errors because so much code is
> @system unnecessarily -> realize what a chore it would be to
> make @trusted interfaces to this code -> remove @safe", you're
> more likely to not have problems at all because the code you
> call is already @safe because that's the default.

Which is another way to say you will loose productivity all the 
time, before you know if that software has any business being 
good in the first place.
Companies write lots of small tools, many of which can (and 
should) be pretty crappy! Else it's just bad focus.
Like I said on Rust context: if you write a hello world, no one 
cares who owns the string "hello world".


> Another result: just by having the compiler option and a
> deprecation cycle started, people will start actually reporting
> problems with @safe, like they are in this thread right now,
> instead of running into those problems and grumbling "eh I
> guess this is half baked, I'll just not use it".

A less charitable view on this is that people don't use @safe 
because it brings them too little value.
"let's make this attribute mandatory because the opt-in version 
isn't successful" is not really Community input.