On Wednesday, 29 May 2013 at 12:41:25 UTC, Adam D. Ruppe wrote:
You would be responsible for freeing the former, but not the slice. So I think keeping them a different type is a feature, not a bug, in this situation.
I have been thinking about this long time ago. Clearly, slice semantics will change in GC-less environment and will require more restrictive operation set. No automatic slice concatenation at the very least.
(Actually I think this would be nice addition to D proper, a special type qualifier that promises you'll never store a reference to this except in local variables. So you can still slice it and so on, but never stuff it in a member variable because the owner might free it without informing you.)
Isn't it what "scope" was supposed to be all about? :) Qualifier that prohibits leaking data outside of the current scope.
And when this is written it might be a good idea to put in phobos too!
Dunno. If something like this can be done, it will need full re-implementation of standard library (similar to minlibd) as assumption made about feature set allowed and druntime differ a lot.
