std.digest toHexString

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, March 16, 2017 20:42:21 Carl Sturtivant via Digitalmars-d-learn 
wrote:
> Implicitly slicing rvalue arrays is too much like implicitly
> taking the address of an rvalue.

Well, that's just it. That's _exactly_ what's happening. It's just that it
ends up in a struct with a length member along with it. You have something
like

struct Array(T)
{
    size_t length;
    T* ptr;
}

instead of

T* ptr;

In both cases, ptr refers to the same address, and each case is exactly as
@safe as the other - as in, not at all.

Unfortunately, for some reason, slicing static arrays has historically been
considered @safe, whereas taking an address of a local variable is
considered @systeme even though they're doing _exactly_ the same thing
except that the slicing ends up with a struct with length instead of just
with a pointer. Fortunately, the @safety improvements that Walter has been
working on should finally fix that.

> I see every reason to remove implicit slicing of rvalue arrays.

Honestly, I think that it was a big mistake to have implicit slicing of
static arrays in the language at all. Unfortunately, last time I tried to
convince Walter of that, he seemed to think that the @safety improvements to
the compiler were going to fix the problem, and they will help, but I'm of
the opinion that slicing of static arrays should always be explicit. It's
too easy to miss what's going on otherwise, even if it isn't an @safety
problem.

In any case, the @safety fixes that are underway should eventually at least
flag this as @system if not result in it being outright illegal. And I think
that there's a good case to make any variant of this issue be illegal if
it's guaranteed that you're going to end up with a pointer to invalid
memory.

- Jonathan M Davis