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

Reply via email to