Copying and in-place methods [was: Why is array truth tied to .ptr?]

[Robert DaSilva]

Leandro Lucarella wrote:
> Robert DaSilva, el 11 de diciembre a las 21:31 me escribiste:
>>> Ok, good catch, maybe that syntax is not right but you missed the big
>>> picture (a compiler generated default implementation for a copying
>>> function that can be overrideable).
>>>
>>> If you now write t.sort.dup(), you are exactly doing that: duplicating t
>>> and then sorting it (in-place I guess). If the implementor has a more
>>> eficient way to use the copy while sorting, you miss that, or you have to
>>> change the syntax (to t.dupsort() for example).
>>>
>> I'm just saying that t.sort.dup() can *only* mean sort t then duplicate
>> what sort returns (an error as sort returns void); unless sort is a
>> struck that overloads opCall, but it's not.
> 
> I was talking about a new feature proposal. I know it doesn't work now.
> 

I'm say it could *NEVER* work because that already has a well defined
behaver and a sub-function can only be called by it's direct parent
function, it own sub-function or sibling sub functions and their
sub-functions, because it *needs* a context pointer to it's parent
functions' stack.