memcpy() comparison: C, Rust, and D

[Nick Treleaven via Digitalmars-d]

On Thursday, 2 February 2017 at 20:37:32 UTC, Random D user wrote:
> What if d had a -safe-defaults switch? It should be ok, since 
> safe is stricter than unsafe right?

Yes, we need this because module-level '@safe:' doesn't allow 
inferrence of @system.

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

Or just override the default with @system when you need it. 
System library code probably can't easily be wrapped with 
@trusted (correctly, see below).

> I myself don't really care for @safe, it's complex and seems to 
> have big practical hole with @trusted.

It's the same as Rust unsafe blocks. Without this 'hole' @safe 
would be much more limited and inefficient, so no one would use 
it. If @trusted is used in a way that exposes unsafe behaviour, 
that is a programmer bug. The good news is, projects shouldn't 
have much @trusted code and it can easily be grepped for.

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

Transitive immutability is very different to shallow const, you 
can't use it so often, but it guarantees safe sharing of data 
across threads or even just string slices in single threaded 
programs without the possibility of accidental modification.