std.digest toHexString

[H. S. Teoh via Digitalmars-d-learn]

On Thu, Mar 16, 2017 at 06:09:52PM +0000, Adam D. Ruppe via Digitalmars-d-learn wrote:
> On Thursday, 16 March 2017 at 17:47:34 UTC, H. S. Teoh wrote:
> > Actually, the bug still exists even if you explicitly slice it:
> > 
> > 	string x = func()[]; // still compiles, but shouldn't
> 
> I don't call that a bug, once it is explicitly done it means the
> programmer realized something is up and decided they are OK with it.
> Perhaps you want to pass it to a function that you know isn't going to
> hold the reference beyond the calling scope.
> 
> > For some reason, slicing a static array return value is somehow OK,
> > while slicing a local variable is rejected.  Seems like the compiler
> > is missing escaping ref checks for return values?
> 
> It's the uniqueness thing, see my last email (I probably was typing it
> at the same time you were typing this...)
> 
> This isn't an escape per se, `string x` is still a local variable.
> 
> immutable(char)[32] buffer;
> string s = buffer[0 .. 16]; // sane and really useful optimization... just
> be careful not to escape it
> 
> Walter wants to expand the escape check so it automatically issues an
> error if you aren't careful enough, but the status quo is still usable
> - such code is not necessarily wrong, banning entirely it is a step
> backward, and programmers coming up the C tradition are used to
> watching lifetimes like that.

Ah, you're right.  And as somebody indicated in the bug comments,
compiling with -dip1000 correctly rejects the `return s;` line as trying
to return a reference to something that's going out of scope.

But in that case, wouldn't that mean implicit slicing isn't to blame
here? (Not that I'm arguing for implicit slicing -- I think it needs to
go, too, having been bitten by it before -- but this particular case
wouldn't constitute as evidence against it.)


T

-- 
Meat: euphemism for dead animal. -- Flora