From slices to perfect imitators: opByValue

[Andrei Alexandrescu via Digitalmars-d]

So there's this recent discussion about making T[] be refcounted if and 
only if T has a destructor.

That's an interesting idea. More generally, there's the notion that 
making user-defined types as powerful as built-in types is a Good Thing(tm).

Which brings us to something that T[] has that user-defined types cannot 
have. Consider:

import std.stdio;

void fun(T)(T x)
{
     writeln(typeof(x).stringof);
}

void main()
{
     immutable(int[]) a = [ 1, 2 ];
     writeln(typeof(a).stringof);
     fun(a);
}

This program outputs:

immutable(int[])
immutable(int)[]

which means that the type of that value has subtly and silently changed 
in the process of passing it to a function.

This change was introduced a while ago (by Kenji I recall) and it 
enabled a lot of code that was gratuitously rejected.

This magic of T[] is something that custom ranges can't avail themselves 
of. In order to bring about parity, we'd need to introduce opByValue 
which (if present) would be automatically called whenever the object is 
passed by value into a function.

This change would allow library designers to provide good solutions to 
making immutable and const ranges work properly - the way T[] works.

There are of course a bunch of details to think about and figure out, 
and this is a large change. Please chime in with thoughts. Thanks!



Andrei