Re: Question about auto ref
Ok I interpret this as a rejection of the idea.
Re: Question about auto ref
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
Re: Question about auto ref
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.
Re: Question about auto ref
auto in? in ref?
Re: Question about auto ref
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.
Re: Question about auto ref
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?
Re: Question about auto ref
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?
Re: Question about auto ref
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.
Re: Question about auto ref
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?
Re: Question about auto ref
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
Re: Question about auto ref
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 jmdavisp...@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
Re: Question about auto ref
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
Re: Question about auto ref
Why is const ref not a good choice?
Re: Question about auto ref
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
Re: Question about auto ref
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
Re: Question about auto ref
Thats the reason why all following declarations behave as const: should be Thats the reason why all following declarations behave as const:
Re: Question about auto ref
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++.
Re: Question about auto ref
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...
Re: Question about auto ref
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
Re: Question about auto ref
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. :)
Re: Question about auto ref
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
Re: Question about auto ref
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.
Re: Question about auto ref
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.
Re: Question about auto ref
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
Re: Question about auto ref
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.
Re: Question about auto ref
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?
Re: Question about auto ref
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
Re: Question about auto ref
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.^^
Re: Question about auto ref
But it works already for templates. So if it's confusing, then, why was it introduced?
Re: Question about auto ref
On Fri, 15 Mar 2013 12:32:35 -0400, Namespace rswhi...@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
Re: Question about auto ref
And it is planned to change the functionality of 'auto ref' to the proposed variant of Jonathan? Or was his proposal rejected?
Re: Question about auto ref
On Fri, 15 Mar 2013 13:15:21 -0400, Namespace rswhi...@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
Re: Question about auto ref
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
Re: Question about auto ref
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.
