On Tue, 05 May 2015 18:58:34 -0400, Namespace <rswhi...@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 <rswhi...@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/ntsyfhesnywfxvzbe...@forum.dlang.org?page=1
http://forum.dlang.org/thread/ylebrhjnrrcajnvtt...@forum.dlang.org?page=1
http://forum.dlang.org/thread/mailman.2989.1356370854.5162.digitalmar...@puremagic.com
http://forum.dlang.org/thread/tkzyjhshbqjqxwzpp...@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/ylebrhjnrrcajnvtt...@forum.dlang.org?page=1
Some more interesting discussion parts:
http://forum.dlang.org/thread/4f84d6dd.5090...@digitalmars.com
http://forum.dlang.org/thread/km3k8v$80p$1...@digitalmars.com?page=1
http://forum.dlang.org/thread/cafdvkcvf6g8mc01tds6ydxqczbfp1q-a-oefvk6bgetwciu...@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
