On Tuesday, 26 March 2013 at 11:41:13 UTC, Namespace wrote:
> I wonder, if someone has already thought about "immutable ref". I can not imagine that many use it, so it wouldn't break (much) code.

immutable ref works (for me) very well. Are there any pitfalls that I can not see?

On Tuesday, March 26, 2013 17:22:29 Namespace wrote:
> On Tuesday, 26 March 2013 at 11:41:13 UTC, Namespace wrote:
> > I wonder, if someone has already thought about "immutable ref". I can not imagine that many use it, so it wouldn't break (much) code.
> 
> immutable ref works (for me) very well. Are there any pitfalls
> that I can not see?

That there's no immutability involved? That would be an incredibly misleading choice. Not to mention, you can probably have a perfectly valid immutable ref right now if you want to pass a an immutable variable by ref, and using immutable ref for this would change its semantics. We probably just need an @something attribute with a good name.

- Jonathan M Davis

how about '&' :

void fun(int & x);

which is same as C++ syntax, hence familiar. I thought someone had proposed that a few weeks ago

On Tue, Mar 26, 2013 at 9:56 AM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> On Tuesday, March 26, 2013 17:22:29 Namespace wrote:
>> On Tuesday, 26 March 2013 at 11:41:13 UTC, Namespace wrote:
>> > I wonder, if someone has already thought about "immutable ref". I can not imagine that many use it, so it wouldn't break (much) code.
>>
>> immutable ref works (for me) very well. Are there any pitfalls
>> that I can not see?
>
> That there's no immutability involved? That would be an incredibly misleading choice. Not to mention, you can probably have a perfectly valid immutable ref right now if you want to pass a an immutable variable by ref, and using immutable ref for this would change its semantics. We probably just need an @something attribute with a good name.
>
> - Jonathan M Davis

On Tuesday, March 26, 2013 10:02:32 Timothee Cour wrote:
> how about '&' :
> 
> void fun(int & x);
> 
> which is same as C++ syntax, hence familiar. I thought someone had proposed that a few weeks ago

That would be a much larger change, and I'd be surprised if Walter or Andrei went for that. Picking an attribute name is much more in line with how we've been doing things.

- Jonathan M Davis

Why is "const ref" not a good choice?

On Tuesday, March 26, 2013 22:55:56 Minas Mina wrote:
> Why is "const ref" not a good choice?

I really don't want to get into that again. There have been a number of discussions on it in the main newsgroup which you can search for, but Andrei considers it to be a major mistake of C++ that const& accepts rvalues, and he does not want to repeat that in D. So, just like ref, const ref in D accepts only lvalues (they're just const instead of mutable), and that's not going to change.

auto ref was introduced specifically to solve the problem of having a function take either lvalues or rvalues efficiently, but Walter misunderstood how Andrei meant for it to work, and the way Walter implemented it only works with templated functions. But we can't change how it works, because it turns out that the way it was implemented has other benefits with regards to forwarding the types of arguments. We have a good idea of how to implement what auto ref should have been. We just need a new attribute for it. It's really not that complicated. It just requires a good name.

- Jonathan M Davis

On Tuesday, March 26, 2013 18:11:42 Jonathan M Davis wrote:
> On Tuesday, March 26, 2013 22:55:56 Minas Mina wrote:
> > Why is "const ref" not a good choice?
> 
> I really don't want to get into that again. There have been a number of discussions on it in the main newsgroup which you can search for, but Andrei considers it to be a major mistake of C++ that const& accepts rvalues, and he does not want to repeat that in D. So, just like ref, const ref in D accepts only lvalues (they're just const instead of mutable), and that's not going to change.

Another thing to consider is that because of how strict D's const is, our solution really should not require that the parameter be const. So, const ref wouldn't work for that unless it were agreed that ref could take rvalues as well, which would create a whole other set of problems.

- Jonathan M Davis

I tried the last few hours to implement something like 'A&' but it's horrible if you haven't complete knowledge and want to implement something that comes after the type...
But what's wrong with '@ref'? If I had knowledge how you could implement new properties I could start a trial.

----

After my attempts to implement something like 'A&' I tried to get something like '@A'. And I was successful.
After that I tried to implement '@ref', but without declare it as a real property (because I just do not know how).
Thats the reason why all following declarations behave as const:

void bar(@ref A a) {

}

void bar(@ ref A a) {

}

void bar(ref@ A a) {

}

void bar(ref @ A a) {

}

For this I had to create a new storage class (currently it is STCref2).

Disadvantage: because @ref is (currently) not a realy property you could place '@' whereever you want (but before the type). But you get an error if you don't use it in combination with 'ref'. I like it. :D
Even if we should prefer a property this is IMO a nice step.
And maybe we could/should change '@' to '&' so that we have 'ref&'/'&ref' what looks like a (nice) combination of D and C++.

"Thats the reason why all following declarations behave as const:"

should be

"Thats the reason why all following declarations behave as const&:"

auto in?
in ref?