www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Question about auto ref

reply "Namespace" <rswhite4 googlemail.com> writes:
In this thread:
http://forum.dlang.org/thread/mailman.2989.1356370854.5162.digitalmars-d puremagic.com
Jonathan suggested that auto ref could work for non-template 
functions like this:
All parameters are declared as ref. For possible rvalues, ​​that 
are passed to this function, temporary variables are created.
Furthermore, Andrei said 
(http://forum.dlang.org/thread/mailman.2989.1356370854.5162.digitalmars-d puremagic.com?page=2#post-kbcc62:24192v:24
:40digitalmars.com) 
that this would work and would be very easy to implement.
As it is never happened and was not even suggested in other 
discussions anymore, there must be a reason why this is a bad 
idea.
Can anyone tell me why? Is it because ref is unsafe at this time? 
Or because 'auto ref' would work then different for non-template 
and template functions?
Mar 15 2013
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 15 Mar 2013 11:54:27 -0400, Namespace <rswhite4 googlemail.com> =
 =

wrote:


 In this thread:
 http://forum.dlang.org/thread/mailman.2989.1356370854.5162.digitalmars=


-d puremagic.com

 Jonathan suggested that auto ref could work for non-template functions=


  =


 like this:
 All parameters are declared as ref. For possible rvalues, =E2=80=8B=E2=


=80=8Bthat are  =


 passed to this function, temporary variables are created.
 Furthermore, Andrei said  =



 (http://forum.dlang.org/thread/mailman.2989.1356370854.5162.digitalmar=


s-d puremagic.com?page=3D2#post-kbcc62:24192v:242:40digitalmars.com)  =


 that this would work and would be very easy to implement.
 As it is never happened and was not even suggested in other discussion=


s  =


 anymore, there must be a reason why this is a bad idea.
 Can anyone tell me why? Is it because ref is unsafe at this time? Or  =



 because 'auto ref' would work then different for non-template and  =



 template functions?


2 Simple reasons:  auto means "infer type", so using auto ref is confusi=
ng  =

the meaning of auto.  For instance, auto ref could actually be valid as =
a  =

return type (the auto is superfluous, but a valid storage class); Second=
,  =

auto ref as currently implemented is useful, and using auto ref for its =
 =

original intended meaning would nix that possibility.

Note, the concept itself is sound, it's just the keyword choice that is =
 =

bad/confusing.

-Steve
Mar 15 2013
parent reply "Namespace" <rswhite4 googlemail.com> writes:
But it works already for templates.
So if it's confusing, then, why was it introduced?
Mar 15 2013
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 15 Mar 2013 12:32:35 -0400, Namespace <rswhite4 googlemail.com>  
wrote:


 But it works already for templates.
 So if it's confusing, then, why was it introduced?


The way it works for templates is to generate two separate functions, one  
which takes ref and one which takes by value.

The proposed auto ref would generate ONE function, and just generate a  
temporary lvalue for any rvalues passed to it.  Templates would not be  
required.

There are pros and cons for both implementations.

The reason it was introduced (and this is hearsay, I was not involved) is  
because Walter misunderstood the original intention.

-Steve
Mar 15 2013
parent reply "Namespace" <rswhite4 googlemail.com> writes:
And it is planned to change the functionality of 'auto ref' to 
the proposed variant of Jonathan? Or was his proposal rejected?
Mar 15 2013
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 15 Mar 2013 13:15:21 -0400, Namespace <rswhite4 googlemail.com>  
wrote:


 And it is planned to change the functionality of 'auto ref' to the  
 proposed variant of Jonathan? Or was his proposal rejected?


I have no idea.  All I know is that Jonathan's proposal is really what  
Andrei wanted originally.

I think we need something like that, whether it's done via auto ref or not.

-Steve
Mar 15 2013
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, March 15, 2013 18:15:21 Namespace wrote:

 And it is planned to change the functionality of 'auto ref' to
 the proposed variant of Jonathan? Or was his proposal rejected?


I don't think that there was any official decision of any kind. IIRC, Kenji was 
looking into at one point and didn't want to use auto ref, because that would 
either mean changing it's meaning for templates (which would actually be a 
problem), or make it so that templated functions couldn't use the new scheme 
(which would also be a problem). I don't remember what attribute he was 
proposing for it though. I'd have to go digging to find out.

Basically, someone needs to implement it and then talk Walter into accepting 
it. That'll be easier for someone like Kenji, who's already a major 
contributor, but in theory, anyone can do it. It's just that there's a high 
risk that the pull request would languish for a while. And it would probably 
need to be implemented with a name other than auto ref in order to avoid the 
aforementioned problems, and having to agree on that could cause further 
delay.

- Jonathan M Davis
Mar 15 2013
next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
So first of all we have to find a new syntax/name?
AFAIK Kenji made ​​a pull request for a new implementation of 
'auto ref' a few months ago. If that was already in the proposed 
manner of Jonathan, we need not to discuss with Walter, because 
the pull is open for months.
Mar 15 2013
prev sibling next sibling parent reply "Namespace" <rswhite4 googlemail.com> writes:
 Basically, someone needs to implement it and then talk Walter 
 into accepting
 it. That'll be easier for someone like Kenji, who's already a 
 major
 contributor, but in theory, anyone can do it.


Are there any tutorials or something similar, which make you a 
bit familiar with the compiler front-end?
Or you have to study the code to learn how it works?
Mar 16 2013
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, March 16, 2013 14:41:37 Namespace wrote:

 Basically, someone needs to implement it and then talk Walter
 into accepting
 it. That'll be easier for someone like Kenji, who's already a
 major
 contributor, but in theory, anyone can do it.


 
 Are there any tutorials or something similar, which make you a
 bit familiar with the compiler front-end?
 Or you have to study the code to learn how it works?


The only thing I'm aware of which explains anything about the compiler outside 
of the compiler's code itself is this page here:

http://prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide

- Jonathan M Davis
Mar 16 2013
parent "Namespace" <rswhite4 googlemail.com> writes:
 The only thing I'm aware of which explains anything about the 
 compiler outside
 of the compiler's code itself is this page here:

 http://prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide

 - Jonathan M Davis


Alright, It seems as if my knowledge is too limited to somehow 
contribute to a solution.^^
Mar 16 2013
prev sibling parent reply "Namespace" <rswhite4 googlemail.com> writes:
 Basically, someone needs to implement it and then talk Walter 
 into accepting
 it. That'll be easier for someone like Kenji, who's already a 
 major
 contributor, but in theory, anyone can do it. It's just that 
 there's a high
 risk that the pull request would languish for a while. And it 
 would probably
 need to be implemented with a name other than auto ref in order 
 to avoid the
 aforementioned problems, and having to agree on that could 
 cause further
 delay.


I am currently working in the required part of the compiler, but 
I need help and other opinions.
So far I've tried both: an implementation for auto ref and ref 
const.

  -> auto ref:
auto ref for non-template functions. In this case (as you had 
suggested it once) temporary variables are created for rvalues. 
Thus the behavior of auto ref would be different for template and 
non-template functions. But I do not see how that would be 
problematic.

  -> ref const:
const ref creates for rvalues a temporary variable that is then 
passed to the function. Advantage: It is like C++. Disadvantage: 
it could break code and you get always a const parameter.

As I said, I've tried both ways before. But I like to hear other 
opinions which of both would be more preferred.
And I would be glad about any kind of help (looking on my code 
etc.).
Maybe we could convince Walter and Andrei with a finished 
implementation.
I hope that no one like to have a new syntax for this kind of 
thing because then we will discuss another year...
Mar 25 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, March 25, 2013 20:43:29 Namespace wrote:

 Basically, someone needs to implement it and then talk Walter
 into accepting
 it. That'll be easier for someone like Kenji, who's already a
 major
 contributor, but in theory, anyone can do it. It's just that
 there's a high
 risk that the pull request would languish for a while. And it
 would probably
 need to be implemented with a name other than auto ref in order
 to avoid the
 aforementioned problems, and having to agree on that could
 cause further
 delay.


 
 I am currently working in the required part of the compiler, but
 I need help and other opinions.
 So far I've tried both: an implementation for auto ref and ref
 const.
 
 -> auto ref:
 auto ref for non-template functions. In this case (as you had
 suggested it once) temporary variables are created for rvalues.
 Thus the behavior of auto ref would be different for template and
 non-template functions. But I do not see how that would be
 problematic.


Because the number of instantiations of the template could grow exponentially 
as the number of auto ref parameters grows. Being able to use the trick with 
the temporary with templated functions could really help reduce template bloat 
when the current meaning of auto ref is not necessary, but that means coming 
up with a new attribute rather than reusing auto ref with non-templated 
functions.


 -> ref const:
 const ref creates for rvalues a temporary variable that is then
 passed to the function. Advantage: It is like C++. Disadvantage:
 it could break code and you get always a const parameter.


Andrei is flat out against this. I wouldn't expect that te over happen.


 As I said, I've tried both ways before. But I like to hear other
 opinions which of both would be more preferred.
 And I would be glad about any kind of help (looking on my code
 etc.).
 Maybe we could convince Walter and Andrei with a finished
 implementation.
 I hope that no one like to have a new syntax for this kind of
 thing because then we will discuss another year...


We pretty much need a new attribute. IIRC, Kenji had a suggestion for what it 
would be, but I don't remember what it was now. I'd have to go digging through 
the archives to find it.

- Jonathan M Davis
Mar 25 2013
parent reply "Namespace" <rswhite4 googlemail.com> writes:
 Because the number of instantiations of the template could grow 
 exponentially
 as the number of auto ref parameters grows. Being able to use 
 the trick with
 the temporary with templated functions could really help reduce 
 template bloat
 when the current meaning of auto ref is not necessary, but that 
 means coming
 up with a new attribute rather than reusing auto ref with 
 non-templated
 functions.


I use the "trick" with the temporary. But why introduce rather a 
new attribute?
I thought the real reason why auto ref was first introduced was 
to solve the rvalue ref problem. Now we could do it. So what's 
wrong with auto ref for non-
template functions?
I'm afraid that the introducing of a new attribute means to spend 
a lot of time. Is that really needed? :/ Or am I wrong?


 Andrei is flat out against this. I wouldn't expect that te over 
 happen.


Good to know.


 We pretty much need a new attribute. IIRC, Kenji had a 
 suggestion for what it
 would be, but I don't remember what it was now. I'd have to go 
 digging through
 the archives to find it.

 - Jonathan M Davis


I haven't heard of it.
Would be very nice if you could do it and post the link. :)
Mar 25 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, March 25, 2013 23:35:06 Namespace wrote:

 Because the number of instantiations of the template could grow
 exponentially
 as the number of auto ref parameters grows. Being able to use
 the trick with
 the temporary with templated functions could really help reduce
 template bloat
 when the current meaning of auto ref is not necessary, but that
 means coming
 up with a new attribute rather than reusing auto ref with
 non-templated
 functions.


 
 I use the "trick" with the temporary. But why introduce rather a
 new attribute?
 I thought the real reason why auto ref was first introduced was
 to solve the rvalue ref problem. Now we could do it. So what's
 wrong with auto ref for non-
 template functions?
 I'm afraid that the introducing of a new attribute means to spend
 a lot of time. Is that really needed? :/ Or am I wrong?


The problem is that we need the temporary trick with templated functions as 
well as non-templated functions. auto ref on templated functions as it stands 
is great for creating parameters that retaining all of the attributes on a 
type - including refness - but it causes template bloat, which in the case 
that auto ref was originally intended to solve is completely unnecessary. The 
temporary trick will work just fine for that, but you can't use auto ref for 
that on templated functions, because we'd lose out on what it currently does, 
which is needed for forwarding arguments (much as it was accidental that we 
got that ability). So, in order to have the temporary trick with templated 
functions, we need a new attribute. That being the caes, there's no point in 
implementing auto ref for non-templated functions, as they should just use the 
same attribute as would be used with template functions.


 I haven't heard of it.
 Would be very nice if you could do it and post the link. :)


I can try, but the search of my e-mail client sucks, so it's always a pain for 
me to find anything in old posts.

- Jonathan M Davis
Mar 25 2013
parent reply "Namespace" <rswhite4 googlemail.com> writes:
I appreciate your efforts and look forward to the link. :)
But I never heard anything about that. How long has it been since 
that was suggested?

But that's honestly sad to hear. I thought I would contribute to 
the solution of this problem. Then we'll have to wait and 
continue to hope.
Mar 25 2013
parent reply "Namespace" <rswhite4 googlemail.com> writes:
Forgot to ask:
Wouldn't it be better to publish this decision?
Many still believe the nonsense (like me) that 'auto ref' is 
still the solution.
Mar 25 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, March 26, 2013 00:52:56 Namespace wrote:

 Forgot to ask:
 Wouldn't it be better to publish this decision?
 Many still believe the nonsense (like me) that 'auto ref' is
 still the solution.


An official decision would mean that Walter had been involved in it, and that 
hasn't happened. IIRC, Andrei said something positive about the temporary 
approach when it was brought up, but AFAIK, no official decision has been made.
It's just that it became clear when discussing it that if we wanted to go with 
the temporary trick (which looks like the best solution), it really should 
apply to both templated and non-templated functions and that auto ref needs to 
retain its current meaning for templated functions, which then means that we 
need a new attribute. I suppose that we could always create a DIP for it 
though.

- Jonathan M Davis
Mar 25 2013
parent reply "Namespace" <rswhite4 googlemail.com> writes:
You make me curious about this new attribute. Maybe I could then 
help to implement this along with its task.
I do not think anyone else has the time to do it.
I hope that you will find the link.
Mar 25 2013
parent reply "Namespace" <rswhite4 googlemail.com> writes:
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.
Mar 26 2013
parent reply "Namespace" <rswhite4 googlemail.com> writes:
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?
Mar 26 2013
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Mar 26 2013
prev sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
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
Mar 26 2013
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Mar 26 2013
parent reply "Minas Mina" <minas_mina1990 hotmail.co.uk> writes:
Why is "const ref" not a good choice?
Mar 26 2013
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Mar 26 2013
parent reply "Minas Mina" <minas_mina1990 hotmail.co.uk> writes:
auto in?
in ref?
Mar 27 2013
parent reply "Namespace" <rswhite4 googlemail.com> writes:
On Wednesday, 27 March 2013 at 09:10:35 UTC, Minas Mina wrote:

 auto in?
 in ref?


in ref was suggested by Kenji and rejected by Jonathan.
What should auto in mean? auto const scope?

I have to say that I like ref&, it's the best of two worlds. :)
We need a clear statement so someone can finally begin.
Mar 27 2013
parent reply "Namespace" <rswhite4 googlemail.com> writes:
So I changed it into 'ref&'.

Quick example:

[code]
void bar1(ref& A a) { } // OK
void bar2(ref &A a) { } // OK
void bar21(&A a) { } // Error: '&' can only be used in 
combination with 'ref'.
void bar22(& A a) { } // Error: '&' can only be used in 
combination with 'ref'.
void bar3(ref const& A a) { } // OK
void bar4(ref const &A a) { } // OK
void bar5(ref &const A a) { } // Error: '&' Must be directly used 
in front of the type.
void bar6(ref& const A a) { } // Error: '&' Must be directly used 
in front of the type.
[/code]

Thoughts?
Mar 27 2013
parent reply "Namespace" <rswhite4 googlemail.com> writes:
I'm surprised that this is ignored and no one seems to be 
interested in a possible solution.
Is it me? Or are my efforts a complete mischief?
Mar 27 2013
parent reply "Namespace" <rswhite4 googlemail.com> writes:
Ok I interpret this as a rejection of the idea.
Mar 29 2013
parent reply Martin Drasar <drasar ics.muni.cz> writes:
On 29.3.2013 11:59, Namespace wrote:

 Ok I interpret this as a rejection of the idea.


This seems like a language design decision and as such would get much
broader audience (and probably more responses) in digitalmars.D than in
learn forum. Threads in here can get overlooked easily.

Maybe you should try some cross-posting...

Martin
Mar 29 2013
parent "Namespace" <rswhite4 googlemail.com> writes:
On Friday, 29 March 2013 at 12:57:55 UTC, Martin Drasar wrote:

 On 29.3.2013 11:59, Namespace wrote:

 Ok I interpret this as a rejection of the idea.


 This seems like a language design decision and as such would 
 get much
 broader audience (and probably more responses) in digitalmars.D 
 than in
 learn forum. Threads in here can get overlooked easily.

 Maybe you should try some cross-posting...

 Martin


Good I will try it.
Mar 29 2013
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Mar 26 2013
parent reply "Namespace" <rswhite4 googlemail.com> writes:
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++.
Mar 26 2013
parent "Namespace" <rswhite4 googlemail.com> writes:
"Thats the reason why all following declarations behave as const:"

should be

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