March 10, 2013
> 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.

Haven't you then not the same problems with 'auto ref'?
But you could prohibit any manipulation of a '&' parameter. Eg. you could make him 'scope' by default (if 'scope' will work someday).
March 10, 2013
> 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.
Yes, you're right. But I also said that the syntax does not matter.
My intention was to stimulate thinking about the real issue.
Even if "auto ref" will work someday for non-templates (we really need an official statement about that), then even small structs will be passed by ref. And that's still very ugly.
March 11, 2013
On Sunday, 10 March 2013 at 19:27:01 UTC, Namespace wrote:
>> 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.
>
> Haven't you then not the same problems with 'auto ref'?
> But you could prohibit any manipulation of a '&' parameter. Eg. you could make him 'scope' by default (if 'scope' will work someday).

As said in another post, I think auto ref suffer pretty much the same problem, but it is less problematic as you can't see the result on rvalues anyway, so the compiler cannot really screw you. It has the inconvenience of taking by ref many thing that would benefit from pass by value.
March 11, 2013
> As said in another post, I think auto ref suffer pretty much the same problem, but it is less problematic as you can't see the result on rvalues anyway, so the compiler cannot really screw you. It has the inconvenience of taking by ref many thing that would benefit from pass by value.

The only problem with this is, that no one knows, if and when 'auto ref' will be implemented for non-templates.
I still hope to an official statement, but I think this is unfortunately unrealistic.
March 11, 2013
On Sunday, 10 March 2013 at 19:27:01 UTC, Namespace wrote:
> But you could prohibit any manipulation of a '&' parameter. Eg. you could make him 'scope' by default (if 'scope' will work someday).

A better solution would be to require that a Parameter with '&' need 'const scope' as storage class.
So the syntax would be:
void foo(in A& a) {
In my opinion, there is then no reason to worry about whether it is an lvalue or an rvalue. It cannot be changed or referenced.

This:
void foo(A& a) {
without const scope would cause an error like : "Error: '&' requires const scope."

AFAIK the syntax 'in ref' was suggested by Kenji but was rejected for some reasons.
March 11, 2013
"deadalnix" <deadalnix@gmail.com> wrote in message news:libldszmvkzcezcfkktx@forum.dlang.org...
> 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.

You're right, I was thinking about const auto ref.  const auto ref could pass values however it felt, and nobody would ever know.


March 12, 2013
On Monday, 11 March 2013 at 10:55:50 UTC, Namespace wrote:
> On Sunday, 10 March 2013 at 19:27:01 UTC, Namespace wrote:
>> But you could prohibit any manipulation of a '&' parameter. Eg. you could make him 'scope' by default (if 'scope' will work someday).
>
> A better solution would be to require that a Parameter with '&' need 'const scope' as storage class.
> So the syntax would be:
> void foo(in A& a) {
> In my opinion, there is then no reason to worry about whether it is an lvalue or an rvalue. It cannot be changed or referenced.
>
> This:
> void foo(A& a) {
> without const scope would cause an error like : "Error: '&' requires const scope."
>
> AFAIK the syntax 'in ref' was suggested by Kenji but was rejected for some reasons.

Your point reminds me of the fact that D has no "inline" or "register" keywords. You probably couldn't pick better experts than the D compiler builders for deciding whether or not those two keywords are necessary. I guess there's not a clear solution to this question, or it would have been settled a while ago. Maybe it should be called the "performance ref" issue, to distinguish it from other ref issues, "@safe ref", "auto ref", etc.
March 12, 2013
On Tuesday, 12 March 2013 at 06:36:32 UTC, Zach the Mystic wrote:
> Your point reminds me of the fact that D has no "inline" or "register" keywords. You probably couldn't pick better experts than the D compiler builders for deciding whether or not those two keywords are necessary. I guess there's not a clear solution to this question, or it would have been settled a while ago. Maybe it should be called the "performance ref" issue, to distinguish it from other ref issues, "@safe ref", "auto ref", etc.

Register keyword make no sense nowadays. Compiler can figure it out way better than you. You could forget about some register keyword and slow down you program for nothing. You could use some register keyword and create bug because you got your aliasing wrong. And all that would require a huge amount of work and clutter the codebase. register keyword is a relic from the past, even in C.

inlining is more subtle. In the general case, compiler get it better than humans, however, it is a much harder problem than register, so being able to hint the compiler may be useful. However, the usage of this is limited to very specific use cases.

I don't see any reason to not allow the compiler to do so and create copy on a per needed basis, by optimizing pass-by value into pass-by-reference when it can prove it doesn't change the semantic (see my thread on the topic, but modify it to apply the restriction to anything possibly aliased).

For the same reason as inline and register, I do think the default behavior is to let the compiler choose what is the bast as long as it doesn't change the final behavior.
March 12, 2013
I also think that we do not need 'inline' or 'register'. Nowadays, compilers can really assess the situation much better than we do.

> I don't see any reason to not allow the compiler to do so and create copy on a per needed basis, by optimizing pass-by value into pass-by-reference when it can prove it doesn't change the semantic (see my thread on the topic, but modify it to apply the restriction to anything possibly aliased).
>
> For the same reason as inline and register, I do think the default behavior is to let the compiler choose what is the bast as long as it doesn't change the final behavior.

I know your thread, I was one of the most active there. And I liked the idea, provided such parameters must be still manually denoted.
And if such parameters are also denoted with 'in' or 'const scope', I see no way that they could be manipulated.
I was hoping that Andrei and Walter could say something about the topic. I like to see something like that and it would solve the 'rvalue ref' problem also.
March 12, 2013
On Tuesday, 12 March 2013 at 08:21:50 UTC, Namespace wrote:
> I also think that we do not need 'inline' or 'register'. Nowadays, compilers can really assess the situation much better than we do.
>
>> I don't see any reason to not allow the compiler to do so and create copy on a per needed basis, by optimizing pass-by value into pass-by-reference when it can prove it doesn't change the semantic (see my thread on the topic, but modify it to apply the restriction to anything possibly aliased).
>>
>> For the same reason as inline and register, I do think the default behavior is to let the compiler choose what is the bast as long as it doesn't change the final behavior.
>
> I know your thread, I was one of the most active there. And I liked the idea, provided such parameters must be still manually denoted.

You never gave any rationale reason on that.
1 2 3 4 5