memcpy() comparison: C, Rust, and D

[Random D user via Digitalmars-d]

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).