• bitwise (13/13) May 03 2015 If I have a large struct that needs to be passed around, like a 4x4 matr...
• rsw0x (5/20) May 03 2015 Use the ref storage class. You can use more than one storage
• bitwise (6/11) May 03 2015 Thanks, this should work.
• rsw0x (8/10) May 03 2015 FYI I'm unsure how well `scope` storage class is currently
• Baz (8/15) May 03 2015 it's specified in http://dlang.org/abi.html (at the bottom):
• Jonathan M Davis via Digitalmars-d-learn (34/47) May 03 2015 std.datetime's use of in is pointless and really should be removed. I
• bitwise (18/35) May 04 2015 How exactly would you move a struct? Just a memcpy without the postblit?
• rsw0x (15/54) May 04 2015 it does, auto ref can bind to both lvalues and rvalues. Create
• bitwise (12/27) May 05 2015 Interesting.. Has this always worked? Theres a couple of forum
• rsw0x (6/32) May 05 2015 I know its worked for a while, I often use it when I'm too lazy
• bitwise (7/19) May 05 2015 I was actually thinking of trying to add it to the table here:
• =?UTF-8?B?QWxpIMOHZWhyZWxp?= (5/7) May 05 2015 It was the same with me. :) Then I wrote a short section about it:
• bitwise (9/10) May 05 2015 ref,%20parameter
• Charles Hixson via Digitalmars-d-learn (3/9) May 06 2015 Are there plans to make this as a book rather than an e-book? I find
• =?UTF-8?B?QWxpIMOHZWhyZWxp?= (8/25) May 06 2015 I was hoping to have it printed before DConf 2015 but it looks like we
• Jonathan M Davis (44/83) May 05 2015 Because D has postblit constructors rather than copy
• bitwise (28/86) May 05 2015 Gotcha.
• Namespace (9/9) May 05 2015 I've discussed that so many times... just search for auto / scope
• bitwise (9/18) May 05 2015 I did read some of these.
• Gomen (1/1) May 05 2015 I am sorry for this post, I am just testing something.
• bitwise (3/4) May 05 2015 The retired "D" forum seems to have been re-purposed for testing ;)
• Namespace (12/32) May 05 2015 We proposed that in DIP 36:
• bitwise (10/47) May 05 2015 +1

bitwise <bitwise.pvt gmail.com> writes:

If I have a large struct that needs to be passed around, like a 4x4 matrix  
for example, how do I do that efficiently in D?

In std.datetime, "in" is used for most struct parameters, but I'm confused  
by the docs for function parameter storage classes[1].

In C++, I would pass a large struct as (const&):
void foo(const Matrix4x4 &m);

Is "in" in D the same as passing by const& in C++? The documentation  
doesn't say anything about "in" being a reference, but it doesn't say that  
"out" parameters are references either, even though it's usage in the  
example clearly shows that it is.

Thanks,
   Bit

http://dlang.org/function.html#parameters

"rsw0x" <anonymous anonymous.com> writes:

On Monday, 4 May 2015 at 01:58:12 UTC, bitwise wrote:
 If I have a large struct that needs to be passed around, like a 
 4x4 matrix for example, how do I do that efficiently in D?

 In std.datetime, "in" is used for most struct parameters, but 
 I'm confused by the docs for function parameter storage 
 classes[1].

 In C++, I would pass a large struct as (const&):
 void foo(const Matrix4x4 &m);

 Is "in" in D the same as passing by const& in C++? The 
 documentation doesn't say anything about "in" being a 
 reference, but it doesn't say that "out" parameters are 
 references either, even though it's usage in the example 
 clearly shows that it is.

 Thanks,
   Bit

 http://dlang.org/function.html#parameters

Use the ref storage class. You can use more than one storage 
class i.e,

foo(in ref int x)

Unless I misunderstood you.

bitwise <bitwise.pvt gmail.com> writes:

On Sun, 03 May 2015 22:37:52 -0400, rsw0x <anonymous anonymous.com> wrote:
 Use the ref storage class. You can use more than one storage class i.e,
 foo(in ref int x)

Thanks, this should work.


On Sun, 03 May 2015 23:29:59 -0400, Baz <bb.temp gmx.com> wrote:
 it's specified in http://dlang.org/abi.html (at the bottom):

 "out and ref are passed as pointers".

Awesome, thanks for the link.

 Maybe `const ref` is what you're looking for...

I'll probably go with "in ref". I think "escape proof" is probably a good  
default. Not to mention, easier to type ;)

"rsw0x" <anonymous anonymous.com> writes:

On Monday, 4 May 2015 at 03:57:04 UTC, bitwise wrote:
 I'll probably go with "in ref". I think "escape proof" is 
 probably a good default. Not to mention, easier to type ;)

FYI I'm unsure how well `scope` storage class is currently 
implemented because it's in a state of flux at the moment as far 
as I know. `in ref` still helps document your intent of the 
parameter however.

It's hard to track this down exactly because scope has so many 
different meanings in D, making it difficult to search for - at 
least one of them has been deprecated.

"Baz" <bb.temp gmx.com> writes:

On Monday, 4 May 2015 at 01:58:12 UTC, bitwise wrote:
 The documentation doesn't say anything about "in" being a 
 reference, but it doesn't say that "out" parameters are 
 references either, even though it's usage in the example 
 clearly shows that it is.

 Thanks,
   Bit

 http://dlang.org/function.html#parameters

it's specified in http://dlang.org/abi.html (at the bottom):

"out and ref are passed as pointers".

The logic seems to be that if it's not specified then it's copied.

Maybe `const ref` is what you're looking for...passed as pointer 
but the compiler will prevent writing the parameter, though it's 
still possible to take the address and to modify the param if the 
function is not  safe.

Jonathan M Davis via Digitalmars-d-learn writes:

On Sunday, May 03, 2015 21:58:12 bitwise via Digitalmars-d-learn wrote:
 If I have a large struct that needs to be passed around, like a 4x4 matrix
 for example, how do I do that efficiently in D?

 In std.datetime, "in" is used for most struct parameters, but I'm confused
 by the docs for function parameter storage classes[1].

 In C++, I would pass a large struct as (const&):
 void foo(const Matrix4x4 &m);

 Is "in" in D the same as passing by const& in C++? The documentation
 doesn't say anything about "in" being a reference, but it doesn't say that
 "out" parameters are references either, even though it's usage in the
 example clearly shows that it is.

 Thanks,
    Bit

 http://dlang.org/function.html#parameters

std.datetime's use of in is pointless and really should be removed. I
misunderstood it at the time I did that. in is essentially an alias for
const scope, and scope does nothing in most cases, basically making it
const, which is generally pointless for a function parameter unless you're
specifically trying to make it so that it can't be mutated inside the
function. And since scope has not even been properly designed (let alone
implemented), I would argue that using in is almost always a bad idea.

The equivalent to const& in D is const ref except that it does not accept
rvalues. So, if you want to be able to do the same, you'll have to do
something like

void foo(ref const Matrix4x4 m)
{
    ...
}

void foo(const Matrix4x4 m)
{
    foo(m);
}

D will move the argument if it can rather than copying it (e.g. if a
temporary is being passed in), which reduces the need for worrying about
copying like you tend to have to do in C++98, and I think that a lot of D
code just doesn't worry about the cost of copying structs. However, if you
have a large object that you know is going to be expensive to copy, you're
either going to have to use const ref (and thus probably duplicate the
function to allow rvalues), or you're going to need to make it a reference
type rather than having all of its data live on the stack (either by making
it so that the struct contains a pointer to its data or by making it a
class). In general, if you're dealing with a type that is going to be
expensive to copy, I'd advise making it a reference type over relying on
const ref simply because it's less error-prone that way. It's trivial to
forget to use ref on a parameter, and generic code won't use it, so it'll
generally work better to just make it a reference type.

- Jonathan M Davis

bitwise <bitwise.pvt gmail.com> writes:

On Mon, 04 May 2015 00:16:03 -0400, Jonathan M Davis via  
Digitalmars-d-learn <digitalmars-d-learn puremagic.com> wrote:
 D will move the argument if it can rather than copying it (e.g. if a
 temporary is being passed in), which reduces the need for worrying about
 copying like you tend to have to do in C++98, and I think that a lot of D
 code just doesn't worry about the cost of copying structs.

How exactly would you move a struct? Just a memcpy without the postblit?

 However, if you have a large object that you know is going to be
 expensive to copy, you're either going to have to use const ref
 (and thus probably duplicate the function to allow rvalues), or
 you're going to need to make it a reference type rather than
 having all of its data live on the stack (either by making
 it so that the struct contains a pointer to its data or by making it a
 class).
 In general, if you're dealing with a type that is going to be
 expensive to copy, I'd advise making it a reference type over relying on
 const ref simply because it's less error-prone that way. It's trivial to
 forget to use ref on a parameter, and generic code won't use it, so it'll
 generally work better to just make it a reference type.

 - Jonathan M Davis

Something like a Matrix4x4 lives in an awkward place between a class and a  
struct. Because of the fact that a graphics engine may have to deal with  
thousands of them per frame, both copying them at function calls, and  
allocating/collecting thousands of them per frame, are both unacceptable.

I was reading up(DIP36, pull requests, forum) and it seems like auto ref  
was supposed to do something like this. Is there a reason you didn't  
mention it?

Why not just add "rvref" to D?

"rvref" would be the same as ref, but would accept an lvalue or an rvalue  
without copying. You could make it const, scope, or whatever you want. It  
would be unsafe if used incorrectly, but thats what regular "ref" is for.  
I suppose additional security could be added though, like making "rvref"  
escape-proof by default. This would introduce no breaking changes and  
facilitate efficient passing of structs.

   Bit

"rsw0x" <anonymous anonymous.com> writes:

On Tuesday, 5 May 2015 at 02:47:03 UTC, bitwise wrote:
 On Mon, 04 May 2015 00:16:03 -0400, Jonathan M Davis via 
 Digitalmars-d-learn <digitalmars-d-learn puremagic.com> wrote:
 D will move the argument if it can rather than copying it 
 (e.g. if a
 temporary is being passed in), which reduces the need for 
 worrying about
 copying like you tend to have to do in C++98, and I think that 
 a lot of D
 code just doesn't worry about the cost of copying structs.

 How exactly would you move a struct? Just a memcpy without the 
 postblit?

 However, if you have a large object that you know is going to 
 be
 expensive to copy, you're either going to have to use const ref
 (and thus probably duplicate the function to allow rvalues), or
 you're going to need to make it a reference type rather than
 having all of its data live on the stack (either by making
 it so that the struct contains a pointer to its data or by 
 making it a
 class).
 In general, if you're dealing with a type that is going to be
 expensive to copy, I'd advise making it a reference type over 
 relying on
 const ref simply because it's less error-prone that way. It's 
 trivial to
 forget to use ref on a parameter, and generic code won't use 
 it, so it'll
 generally work better to just make it a reference type.

 - Jonathan M Davis

 Something like a Matrix4x4 lives in an awkward place between a 
 class and a struct. Because of the fact that a graphics engine 
 may have to deal with thousands of them per frame, both copying 
 them at function calls, and allocating/collecting thousands of 
 them per frame, are both unacceptable.

 I was reading up(DIP36, pull requests, forum) and it seems like 
 auto ref was supposed to do something like this. Is there a 
 reason you didn't mention it?

it does, auto ref can bind to both lvalues and rvalues. Create 
the function with an empty template like so,

import std.stdio;

struct S{
}

void Foo()(auto ref S s){
}

void main(){
	S s;
	Foo(s);
	Foo(S());
}

There might be other ways that I'm unaware of.

 Why not just add "rvref" to D?

D is already bloated.

bitwise <bitwise.pvt gmail.com> writes:

On Tue, 05 May 2015 00:20:15 -0400, rsw0x <anonymous anonymous.com> wrote:
 it does, auto ref can bind to both lvalues and rvalues. Create the  
 function with an empty template like so,

 import std.stdio;

 struct S{
 }

 void Foo()(auto ref S s){
 }

 void main(){
 	S s;
 	Foo(s);
 	Foo(S());
 }

 There might be other ways that I'm unaware of.

Interesting.. Has this always worked? Theres a couple of forum  
conversations about trying to get "auto ref" to work for non-templates.  
The main problem seems to be that auto ref wont work for virtual  
functions. Also, I don't see how someone could arrive at the above  
solution without showing up here and asking first.

 Why not just add "rvref" to D?

 D is already bloated.

Some of the discussions about auto ref seem to have arrived at the idea  
that adding a keyword is the only way fix this without changing existing  
behavior or adding new behavior that would share syntax with old behavior  
and be confusing.

Anyways, for my purposes, templates will do fine, so thanks!

   Bit

"rsw0x" <anonymous anonymous.com> writes:

On Tuesday, 5 May 2015 at 14:14:51 UTC, bitwise wrote:
 On Tue, 05 May 2015 00:20:15 -0400, rsw0x 
 <anonymous anonymous.com> wrote:
 it does, auto ref can bind to both lvalues and rvalues. Create 
 the function with an empty template like so,

 import std.stdio;

 struct S{
 }

 void Foo()(auto ref S s){
 }

 void main(){
 	S s;
 	Foo(s);
 	Foo(S());
 }

 There might be other ways that I'm unaware of.

 Interesting.. Has this always worked? Theres a couple of forum 
 conversations about trying to get "auto ref" to work for 
 non-templates. The main problem seems to be that auto ref wont 
 work for virtual functions.

I know its worked for a while, I often use it when I'm too lazy 
to put attributes in and just have the templates infer them for 
me ;)

 Also, I don't see how someone could arrive at the above 
 solution without showing up here and asking first.

You're probably right, maybe someone should submit a PR to 
https://github.com/p0nce/d-idioms/

bitwise <bitwise.pvt gmail.com> writes:

On Tue, 05 May 2015 10:44:13 -0400, rsw0x <anonymous anonymous.com> wrote:

 On Tuesday, 5 May 2015 at 14:14:51 UTC, bitwise wrote:
 Interesting.. Has this always worked? Theres a couple of forum  
 conversations about trying to get "auto ref" to work for non-templates.  
 The main problem seems to be that auto ref wont work for virtual  
 functions.

 I know its worked for a while, I often use it when I'm too lazy to put  
 attributes in and just have the templates infer them for me ;)

Nice ;)

 Also, I don't see how someone could arrive at the above solution  
 without showing up here and asking first.

 You're probably right, maybe someone should submit a PR to  
 https://github.com/p0nce/d-idioms/

I was actually thinking of trying to add it to the table here:

http://dlang.org/function.html#parameters

It's on the template page, but as it is truly the only way to ensure  
structs are passed efficiently, it may be a good idea to add a link, or  
some text on this page as well.

=?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:

On 05/05/2015 07:14 AM, bitwise wrote:

 I don't see how someone could arrive at the above
 solution without showing up here and asking first.

It was the same with me. :) Then I wrote a short section about it:

 
http://ddili.org/ders/d.en/lvalue_rvalue.html#ix_lvalue_rvalue.auto%20ref,%20parameter

Ali

bitwise <bitwise.pvt gmail.com> writes:

On Tue, 05 May 2015 14:49:07 -0400, Ali =C7ehreli <acehreli yahoo.com> w=
rote:
 http://ddili.org/ders/d.en/lvalue_rvalue.html#ix_lvalue_rvalue.auto%20=

ref,%20parameter

I've actually stumbled upon this site a few times, and it has been very =
 =

helpful, so thanks =3DD

Unfortunately though, I had no idea that "auto ref" was what I was looki=
ng  =

for in the first place =3D/

Charles Hixson via Digitalmars-d-learn writes:

On 05/05/2015 11:49 AM, Ali Çehreli via Digitalmars-d-learn wrote:
 On 05/05/2015 07:14 AM, bitwise wrote:

 I don't see how someone could arrive at the above
 solution without showing up here and asking first.

 It was the same with me. :) Then I wrote a short section about it:


 http://ddili.org/ders/d.en/lvalue_rvalue.html#ix_lvalue_rvalue.aut
%20ref,%20parameter 


 Ali

Are there plans to make this as a book rather than an e-book?  I find 
books much more useful.

=?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:

On 05/06/2015 11:24 AM, Charles Hixson via Digitalmars-d-learn wrote:
 On 05/05/2015 11:49 AM, Ali Çehreli via Digitalmars-d-learn wrote:
 On 05/05/2015 07:14 AM, bitwise wrote:

 I don't see how someone could arrive at the above
 solution without showing up here and asking first.

 It was the same with me. :) Then I wrote a short section about it:


 http://ddili.org/ders/d.en/lvalue_rvalue.html#ix_lvalue_rvalue.auto%20ref,%20parameter


 Ali

 Are there plans to make this as a book rather than an e-book?  I find
 books much more useful.

I was hoping to have it printed before DConf 2015 but it looks like we 
will be missing that date.

I have to credit especially Luís Marques for his excellent work as the 
editor (who happens to be more qualified than I for writing this book 
anyway). Neither he nor I want to rush this before feeling good about 
the result.

Ali

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

On Tuesday, 5 May 2015 at 02:47:03 UTC, bitwise wrote:
 On Mon, 04 May 2015 00:16:03 -0400, Jonathan M Davis via 
 Digitalmars-d-learn <digitalmars-d-learn puremagic.com> wrote:
 D will move the argument if it can rather than copying it 
 (e.g. if a
 temporary is being passed in), which reduces the need for 
 worrying about
 copying like you tend to have to do in C++98, and I think that 
 a lot of D
 code just doesn't worry about the cost of copying structs.

 How exactly would you move a struct? Just a memcpy without the 
 postblit?

Because D has postblit constructors rather than copy 
constructors, copying is done by blitting the entire struct and 
then calling the postlblit constructor afterwards, so unless the 
postlbit constructor is  disabled, a struct is moveable simply by 
blitting it and not calling the postblit constructor afterwards. 
And the compiler can choose to do a move whenever a copy is 
unnecessary (e.g. return value optimization or when a temporary 
is passed to a

 However, if you have a large object that you know is going to 
 be
 expensive to copy, you're either going to have to use const ref
 (and thus probably duplicate the function to allow rvalues), or
 you're going to need to make it a reference type rather than
 having all of its data live on the stack (either by making
 it so that the struct contains a pointer to its data or by 
 making it a
 class).
 In general, if you're dealing with a type that is going to be
 expensive to copy, I'd advise making it a reference type over 
 relying on
 const ref simply because it's less error-prone that way. It's 
 trivial to
 forget to use ref on a parameter, and generic code won't use 
 it, so it'll
 generally work better to just make it a reference type.

 - Jonathan M Davis

 Something like a Matrix4x4 lives in an awkward place between a 
 class and a struct. Because of the fact that a graphics engine 
 may have to deal with thousands of them per frame, both copying 
 them at function calls, and allocating/collecting thousands of 
 them per frame, are both unacceptable.

 I was reading up(DIP36, pull requests, forum) and it seems like 
 auto ref was supposed to do something like this. Is there a 
 reason you didn't mention it?

You could use auto ref, but then you'd have to templatize the 
function, since it only works with templated functions, and if 
you have multiple auto ref parameters, then you'll get a 
combinatorial explosion of template instantations as you call the 
function with different combinations of lvalues and rvalues. It's 
basically like declaring each of the combinations of the function 
with ref and non-ref parameters, but you don't have to declare 
them all, and it doesn't work with virtual functions. I didn't 
mention auto ref mostly just to be simple.

But because of that combinatorial explosion (be they declared 
implicitly via auto ref or manually) is a good reason IMHO to 
just not worry about this problem in most cases. It's just too 
tedious to duplicate all functions like that, and using templates 
isn't always acceptable.

In theory, auto ref could work for non-templated functions by 
making it so that underneath the hood as ref except that any time 
you passed it an rvalue, it implicitly defined an lvalue for you 
to pass to the function, but that doesn't match what happens with 
auto ref with non-templated functions, and changing the behavior 
for templated functions would be unacceptable, because it would 
reduce our ability to forward parameters without changing their 
type, so we'd end up with auto ref doing different things on 
templated and non-templated functions, which is potentially 
confusing. And that solution has simply never been agreed upon. I 
have no idea if it ever will be.

 Why not just add "rvref" to D?

Because we have too many attributes already. It's actually kind 
of astonishing that we're getting return ref, because Andrei was 
adamant that we not add any more parameter attributes, because we 
simply have too many already. I think that the only reasons that 
return ref is making it in is because of how it solves a real 
need and how simple it is, whereas Andrei is not at all convinced 
that having anything like C++'s const& in D is needed. And while 
it might be nice, for the most part, we _are_ able to mostly 
write code without worrying about it.

- Jonathan M Davis

bitwise <bitwise.pvt gmail.com> writes:

On Tue, 05 May 2015 11:54:53 -0400, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 On Tuesday, 5 May 2015 at 02:47:03 UTC, bitwise wrote:
 On Mon, 04 May 2015 00:16:03 -0400, Jonathan M Davis via  
 Digitalmars-d-learn <digitalmars-d-learn puremagic.com> wrote:
 D will move the argument if it can rather than copying it (e.g. if a
 temporary is being passed in), which reduces the need for worrying  
 about
 copying like you tend to have to do in C++98, and I think that a lot  
 of D
 code just doesn't worry about the cost of copying structs.

 How exactly would you move a struct? Just a memcpy without the postblit?

 Because D has postblit constructors rather than copy constructors,  
 copying is done by blitting the entire struct and then calling the  
 postlblit constructor afterwards, so unless the postlbit constructor is  
  disabled, a struct is moveable simply by blitting it and not calling  
 the postblit constructor afterwards. And the compiler can choose to do a  
 move whenever a copy is unnecessary (e.g. return value optimization or  
 when a temporary is passed to a

Gotcha.

Correct me if I'm wrong though, but in C++(and I don't see why D would be  
different), RVO removes the need for the struct/class to be blitted  
completely. The struct/class will simply be constructed directly to the  
return address to begin with.

I don't see how the above could achieved with parameter passing(by value),  
which is why I suggest rvref.


 Something like a Matrix4x4 lives in an awkward place between a class  
 and a struct. Because of the fact that a graphics engine may have to  
 deal with thousands of them per frame, both copying them at function  
 calls, and allocating/collecting thousands of them per frame, are both  
 unacceptable.

 I was reading up(DIP36, pull requests, forum) and it seems like auto  
 ref was supposed to do something like this. Is there a reason you  
 didn't mention it?

 You could use auto ref, but then you'd have to templatize the function,  
 since it only works with templated functions, and if you have multiple  
 auto ref parameters, then you'll get a combinatorial explosion of  
 template instantations as you call the function with different  
 combinations of lvalues and rvalues. It's basically like declaring each  
 of the combinations of the function with ref and non-ref parameters, but  
 you don't have to declare them all, and it doesn't work with virtual  
 functions. I didn't mention auto ref mostly just to be simple.

 But because of that combinatorial explosion (be they declared implicitly  
 via auto ref or manually) is a good reason IMHO to just not worry about  
 this problem in most cases. It's just too tedious to duplicate all  
 functions like that, and using templates isn't always acceptable.

 In theory, auto ref could work for non-templated functions by making it  
 so that underneath the hood as ref except that any time you passed it an  
 rvalue, it implicitly defined an lvalue for you to pass to the function,  
 but that doesn't match what happens with auto ref with non-templated  
 functions, and changing the behavior for templated functions would be  
 unacceptable, because it would reduce our ability to forward parameters  
 without changing their type, so we'd end up with auto ref doing  
 different things on templated and non-templated functions, which is  
 potentially confusing. And that solution has simply never been agreed  
 upon. I have no idea if it ever will be.


I'm not really worried about the symbol explosion, because most of the  
functions I would be using would be binary at most. I'm more worried about  
losing the ability to use virtual/non-templated functions with  
lvalue+rvalue refs.

I really do believe this should be fixed. D SHOULD have a way to pass a  
large struct parameter as a ref whether its an lvalue or an rvalue without  
copying. And when I say copying, this includes blitting without calling  
postblit, which would still be quite pricey for something like a  
Matrix4x4(64 bytes for floats) if it had to happen thousands of times per  
frame in real time. And trading these thousands of copies for  
allocations/collections is just as bad.

 Why not just add "rvref" to D?

 Because we have too many attributes already. It's actually kind of  
 astonishing that we're getting return ref, because Andrei was adamant  
 that we not add any more parameter attributes, because we simply have  
 too many already. I think that the only reasons that return ref is  
 making it in is because of how it solves a real need and how simple it  
 is, whereas Andrei is not at all convinced that having anything like 
 C++'s const& in D is needed. And while it might be nice, for the most  
 part, we _are_ able to mostly write code without worrying about it.

I do understand this, but what's more astonishing is that things have  
gotten this far and there isn't as way to pass a struct without making  
unnecessary copies ;)

In a practical sense, I suppose templates/auto ref will mitigate the  
problem _well_enough_ for now, but it's an hack that only works with  
templates and my code will still be creating copies all over the place for  
no reason.

   Bit

"Namespace" <rswhite4 gmail.com> writes:

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

bitwise <bitwise.pvt gmail.com> writes:

On Tue, 05 May 2015 17:33:09 -0400, Namespace <rswhite4 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

"Gomen" <gomen asai.jp> writes:

I am sorry for this post, I am just testing something.

bitwise <bitwise.pvt gmail.com> writes:

On Tue, 05 May 2015 18:27:54 -0400, Gomen <gomen asai.jp> wrote:

 I am sorry for this post, I am just testing something.

The retired "D" forum seems to have been re-purposed for testing ;)

   Bit

"Namespace" <rswhite4 gmail.com> writes:

On Tuesday, 5 May 2015 at 21:58:57 UTC, bitwise wrote:
 On Tue, 05 May 2015 17:33:09 -0400, Namespace 
 <rswhite4 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

As you can see there are debate for ages. Many people of the 
community really wants a solution, but since Andrei and Walter 
believe that it brings no real benefit, nothing has changed. I 
stuck with auto ref + templates if I need lvalues + rvalues 
(which is often the case in game dev).

bitwise <bitwise.pvt gmail.com> writes:

On Tue, 05 May 2015 18:58:34 -0400, Namespace <rswhite4 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 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