On Wednesday, 1 February 2017 at 23:49:29 UTC, H. S. Teoh wrote:
We would love to change the defaults, but unfortunately that
boat has already sailed a long time ago.
What if d had a -safe-defaults switch? It should be ok, since
safe is stricter than unsafe right?
This way old/existing code would compile fine by default, but if
you want to use that code/lib with safe-defaults you either have
to do trusted wrappers or modify it to be safe.
All new code with safe-defaults would compile fine in safe mode
and unsafe mode.
To me it's similar approach to 'warnings-all' and
'warnings-as-errors'.
---
I myself don't really care for @safe, it's complex and seems to
have big practical hole with @trusted. Kind of like 'refs can't
be null in c++' (as some people claim/argue) and then someone
passes nullptr into function ref arg. Completely unreliable, even
though refs usually work ok 99% of the time (by conventions and
effort).
I've already thrown const, immutable, inout mostly in to trash
(string literals etc. are exception) after few tries. They make
the code more complex and harder to modify especially when you
have bigger system. Often you realize that your system/module
isn't truly 100% const in the last insignificant leaf function,
and that triggers large cascading modifications and rewrites,
just to get the code work. Also I can't really remember when I
accidentally modified data that I shouldn't have (i.e. violate
const protection). But I often modify correct data incorrectly. I
believe most programmers first figure out what they need to do
before doing it instead of just writing randomly into some
array/pointer that looked handy :)
I prefer flexible (fun), fast and debuggable (debugger/printing
friendly) code. It seems that neither @safe or const are part of
it. (I'm not writing life and death safety critical code anyway).
