Does D really need something like const&?

[Era Scarecrow]

On Saturday, 2 March 2013 at 08:29:25 UTC, Namespace wrote:
> Era Scarecrow:
> Did I understand right that your answer is 'No, we don't need 
> something like const&'?

const& is ugly and suggests it is using a pointer which we don't 
want to use except in low level stuff. const& doesn't make sense, 
but 'auto ref' does, and I think it could be quite useful.



On Saturday, 2 March 2013 at 09:38:17 UTC, deadalnix wrote:
> On Saturday, 2 March 2013 at 09:31:56 UTC, Namespace wrote:
>> On Saturday, 2 March 2013 at 09:38:17 UTC, deadalnix wrote:
>>> 1/ Generic code. You may not know that the data are big after 
>>> starting conglomerating more and more stuff.
>> auto ref for templates still exists and won't get away.
>
> Passing by ref small struct for nothing is also a performance 
> concern. You'll access them via dereference when you could have 
> them directly in registers, and reduce the compiler capability 
> of doing optimization based on aliasing.
>
> Auto ref is convenient, but look more like an ugly patch than a 
> real solution.

  And if it's not implemented I'll be doomed making the same 
forwarding functions due to ref & const preference rules. I can 
live with it but I don't want to. I'm not saying I'll use auto 
ref for everything, only when it makes sense to.

>>> 2/ Data may be small, but with an expensive copy mechanism.
>> Example?
>
> struct ValueArray(T) {
>     T[] data;
>     alias this = data; // Damned, it is broken on 2.062
>
>     this(this) {
>         data = data.dup;
>     }
> }

  Perhaps enlarge the example just a touch...

   alias ValueArray!ubyte BigUbArray;
   BigUbArray array = new ubyte[1<<20]; //1 meg
   static assert(BigUbArray.sizeof <= 16);

   //gee 'BigUbArray' is only 8-16 bytes!!! postblit!
   void func(BigUbArray s);

  If it's POD however then it shouldn't have any 
modifications/postblit or anything special to worry about.