On Thu, Mar 16, 2017 at 05:06:39PM +0000, Adam D. Ruppe via Digitalmars-d-learn
wrote:
[...]
> In isolation, implicit slicing can make sense.... but not with
> templates. In isolation, implicit immutable can make sense... but not
> with implicit slicing.
[...]
Is implicit slicing the culprit in the issue I just filed? (Bug 17261)
In retrospect, perhaps implicit casting to immutable is OK if we don't
allow implicit slicing:
char[32] func() { char[32] s; return s; }
string gunk() {
string x = func(); // error, if implicit slicing is not allowed
return x; // if allowed, this causes escaping ref to
stack data
}
immutable char[32] hunk() {
immutable char[32] x = func(); // should be OK: no implicit
slicing
return x; // OK: return by-value, no escaping refs
}
string junk() {
immutable char[32] x = func(); // should be OK: no implicit
slicing
return x; // NG: implicit slicing causes escaping ref
// However, compiler is smart enough to catch
// it, so it produces a compile error
}
Seems like the real cause of bug 17261 is implicit slicing.
T
--
Debugging is twice as hard as writing the code in the first place. Therefore,
if you write the code as cleverly as possible, you are, by definition, not
smart enough to debug it. -- Brian W. Kernighan