Efficiently passing structs

[bitwise via Digitalmars-d-learn]

On Tue, 05 May 2015 18:58:34 -0400, Namespace <rswhite4 at gmail.com> wrote:

> On Tuesday, 5 May 2015 at 21:58:57 UTC, bitwise wrote:
>> On Tue, 05 May 2015 17:33:09 -0400, Namespace <rswhite4 at gmail.com>  
>> wrote:
>>
>>> I've discussed that so many times... just search for auto / scope  
>>> ref... ;)
>>> It will never happen.
>>>
>>> See:
>>> http://forum.dlang.org/thread/ntsyfhesnywfxvzbemwc@forum.dlang.org?page=1
>>> http://forum.dlang.org/thread/ylebrhjnrrcajnvtthtt@forum.dlang.org?page=1
>>> http://forum.dlang.org/thread/mailman.2989.1356370854.5162.digitalmars-d@puremagic.com
>>> http://forum.dlang.org/thread/tkzyjhshbqjqxwzppdin@forum.dlang.org#post-mailman.2965.1356319786.5162.digitalmars-d-learn:40puremagic.com
>>> http://forum.dlang.org/thread/hga1jl$18hp$1@digitalmars.com
>>
>> I did read some of these.
>>
>> Has anyone brought up simply allowing "in ref" or "const scope ref" to  
>> accept rvalues? If DIPs 69 and 25 were implemented, I don't see why  
>> this would be a problem. I agree that "const ref" should not, but I  
>> don't see a problem with "const scope ref".
>>
>> I haven't seen a conversation that was strongly in favor of DIP 36. Why  
>> hasn't it been rejected?
>>
>>   Bit
>
> We proposed that in DIP 36:
> http://forum.dlang.org/thread/ylebrhjnrrcajnvtthtt@forum.dlang.org?page=1
>
> Some more interesting discussion parts:
> http://forum.dlang.org/thread/4F84D6DD.5090405@digitalmars.com
> http://forum.dlang.org/thread/km3k8v$80p$1@digitalmars.com?page=1
> http://forum.dlang.org/thread/CAFDvkcvf6G8Mc01Tds6ydXqCZbfp1q-a-oeFVk6BGEtwCiUAqg@mail.gmail.com

Awesome, thanks for the links. I haven't read all of these yet.

> Many people of the community really wants a solution

+1

> I stuck with auto ref + templates if I need lvalues + rvalues (which is  
> often the case in game dev).

Yeah... structs/template-auto-ref is fine for matrices, vectors,  
quaternions, colors, etc, but I'm not gonna be able to get away with that  
for any kind of shared assets like textures, materials, etc, etc.. so I  
hope this eventually gets fixed.

> but since Andrei and Walter believe that it brings no real benefit,  
> nothing has changed.

I suppose this is like the C++ argument "always use std::vector instead of  
std::list because CACHE!", but there's a time and place for everything..

   Bit