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
