March 10, 2013
> You don't mark it with '&'.

Oh, then I understood you wrong.
I thought you meant that the compiler for each struct parameters (whether marked or not) just automatically perform such changes.

>>> Then you only need one version of the function.  We could
>>> use auto ref for this.
>> 'auto ref' will probably never work for non-template functions, as Jonathan said some time ago.
>
> That is not my understanding.

Read my thread 'auto ref - again'.
March 10, 2013
"Namespace" <rswhite4@googlemail.com> wrote in message news:aucfrmomyneucfykpmap@forum.dlang.org...
>>>> Then you only need one version of the function.  We could use auto ref for this.
>>> 'auto ref' will probably never work for non-template functions, as Jonathan said some time ago.
>>
>> That is not my understanding.
>
> Read my thread 'auto ref - again'.

If Jonathan made this claim in there, I must have missed it.  Regardless, there is an open pull request that implements auto ref, which has not been accepted or rejected yet.


March 10, 2013
> If Jonathan made this claim in there, I must have missed it.  Regardless,
> there is an open pull request that implements auto ref, which has not been
> accepted or rejected yet.

Like I said, read the thread. Or better, read all my threads on this topic.
March 10, 2013
"Namespace" <rswhite4@googlemail.com> wrote in message news:hlsfrzwwmwtepuidxgrt@forum.dlang.org...
>> If Jonathan made this claim in there, I must have missed it.  Regardless,
>> there is an open pull request that implements auto ref, which has not
>> been
>> accepted or rejected yet.
>
> Like I said, read the thread. Or better, read all my threads on this topic.

I have better things to do.


March 10, 2013
Then just believe me. I have discussed the theme of 'auto ref' a lot of times.
And I would be still happy if 'auto ref' would also work for non-template functions. But I just think my idea still goes a step further. After all, it takes into account the problem of moving large structs.
March 10, 2013
On Saturday, 9 March 2013 at 23:07:50 UTC, Ali Çehreli wrote:
> On 03/09/2013 12:19 PM, Namespace wrote:
>
> > But structs with a bigger size aren't that performant if you
> pass them
> > as copy or move them (See also my small benchmark:
>
> I have started working on the DConf presentation about copy and move semantics in D. I have done exactly the same type of tests and was surprised how faster pass-by-reference can be.
>
> To be fair, I have also accessed the members of the structs inside the function to see whether the pointer dereferencing in the by-ref case brought any cost. Apparently I have been ignorant in modern CPU designs because I was surprised to see that pointer dereferencing seemingly had no cost at all. My guess would be that the object is completely inside the processor's cache.
>

Have you checked the assembly to see if a dereference actually happened ?

This should be performant anyway, because the stack frame is likely to be in cache.

> Then I suspected dmd and made similar tests with gcc in the C language and have seen similar results. So yes, apparently by-ref is faster at least in some cases.
>

Indeed, if the struct is big enough or the copy expensive !

> > The compiler will check by these kind of parameters if they
> are structs
> > and if the size is proven greater as N (maybe 16 - 24) bit.
> If not, the
> > '&' will be ignored. The function take in this cases normally
> lvalues as
> > copy and moves rvalues.
> > But if the struct size is greater than N the compiler changes
> the
> > storage class of this parameter to ref.
>
> I hope others with compiler knowledge will chime in here.
>
> I think the type of the parameter that is passed is intrinsic to how the function gets compiled. I think, for that to work, the compiler would have to compile two versions of the function, one taking by-value and the other taking by-ref.
>
> If what I said above is correct, then of course that wouldn't scale, e.g. we would need four separate compilations of the function if we had two parameters.
>

I don't think so. Many function's parameters aren't electible to such mecanism (or it'd be a bug) and many type don't gain to be passed by ref (small struct, like slice, delegate, a very large amount in fact).

> Then there would be the issue of finding a naming scheme for these separate versions of the function so that the linker finds the right one. I am making up some names for the linker: foo_val_val(), foo_val_ref(), foo_ref_val(), foo_ref_ref().
>

Yes, mangling must be affected, but I don't think this is that bad.
March 10, 2013
Too bad, I had hoped for a little more discussion / feedback on this topic.
Is it a good idea or a bad one. It is complete nonsense or has it been a right to exist, etc.
What's wrong with you guys?
March 10, 2013
On Saturday, 9 March 2013 at 20:19:10 UTC, Namespace wrote:
> So I like to suggest a new syntax for this behaviour.
> If you want that your function/method/whatever takes a struct as well as rvalue and lvalue, you declare this parameter with a '&' (Or whatever, the syntax doesn't matter at all. I like the '&' because I know it from C++ and many (C++) Newcomer will know what it means. Furthermore '&' is a lot shorter than eg. 'auto ref').

I don't think this is a good idea for several reasons.

First, it introduce a new syntax, which is always a concern. It add language complexity, and it likely to not be used everywhere it should.

Second, the default behavior must be the most beneficial one. Simply because it will be the most used, and we don't want good code to be crippled with many addition here and there. Providing a default suboptimal behavior (here performancewise).

Finally, I think this behavior is very dangerous. Pass by reference and value have very different. With that construct, you'll never know which one you get as the compiler decide ! If the compiler and not the programmer decide what the program does (not implementation wise, but semantically), we have a problem.
March 10, 2013
On Sunday, 10 March 2013 at 02:17:36 UTC, Daniel Murphy wrote:
> A better way to do with would be to change (or extend) the abi, so that
> structs over a certain size are always passed by reference with this
> parameter type.  Then you only need one version of the function.  We could
> use auto ref for this.

Auto ref will pass any lvalue by ref, even when it don't make any sense (small structs). It also expose different semantic according if an revalue or an lvalue is passed. It has roughly the same issues as this thread's proposal.
March 10, 2013
On 3/10/13 2:57 PM, Namespace wrote:
> Too bad, I had hoped for a little more discussion / feedback on this topic.
> Is it a good idea or a bad one. It is complete nonsense or has it been a
> right to exist, etc.
> What's wrong with you guys?

I can't hear or read "what's wrong with you" without remembering about https://www.youtube.com/watch?v=nV7u1VBhWCE...

Andrei