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.

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

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

On Tue, 05 May 2015 14:49:07 -0400, Ali Çehreli <acehreli@yahoo.com> wrote:
> http://ddili.org/ders/d.en/lvalue_rvalue.html#ix_lvalue_rvalue.auto%20ref,%20parameter

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

Unfortunately though, I had no idea that "auto ref" was what I was looking for in the first place =/

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 likeC++'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

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

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

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

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

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).