www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - auto ref - again

reply "Namespace" <rswhite4 googlemail.com> writes:
In relation to this post: 
http://forum.dlang.org/thread/ssiulznvtkmfkimmatpk forum.dlang.org?page=5#post-knnghuzbzqddaqcjtvch:40forum.dlang.org
I hereby open up again the discussion about auto ref.
There are only some questions: Will auto ref be implemented in 
the near future or not? If not, with which version it will 
probably come?
Or is auto ref forgotten and we have to discuss about the need 
and the syntax again?
There is still a pull from Kenji (#1019) which is waiting for 
completion and merging (thanks for that, Kenji).
But it seems that this whole topic isn't that important (or am I 
wrong?), but the need for such feature is still there, 
exceedingly since with dmd 2.061 structs aren't lvalues anymore. 
We need const& for D. Without that, massive struct usage is very 
unhandy.
I hope for an official statement from Walter and/or Andrei. Let 
the games begin.

And in advance: I'm from Germany, so English is not my native 
language. So forgive my bad English.
Jan 26 2013
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/26/13 6:03 AM, Namespace wrote:
 In relation to this post:
 http://forum.dlang.org/thread/ssiulznvtkmfkimmatpk forum.dlang.org?page=5#post-knnghuzbzqddaqcjtvch:40forum.dlang.org

 I hereby open up again the discussion about auto ref.
 There are only some questions: Will auto ref be implemented in the near
 future or not?

Yes. We are actively looking into a complete solution. Along the way we also very strongly want to define semantics of "ref" in such a way that makes unsafe escapes impossible. These two features are related. Andrei
Jan 26 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 Yes. We are actively looking into a complete solution. Along 
 the way we also very strongly want to define semantics of "ref" 
 in such a way that makes unsafe escapes impossible. These two 
 features are related.

 Andrei

That's good to know. But can you estimate _when_ it will be implemented or with which version? That would be very informative.
Jan 26 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 26 January 2013 at 16:27:04 UTC, Andrei Alexandrescu 
wrote:
 On 1/26/13 6:03 AM, Namespace wrote:
 In relation to this post:
 http://forum.dlang.org/thread/ssiulznvtkmfkimmatpk forum.dlang.org?page=5#post-knnghuzbzqddaqcjtvch:40forum.dlang.org

 I hereby open up again the discussion about auto ref.
 There are only some questions: Will auto ref be implemented in 
 the near
 future or not?

Yes. We are actively looking into a complete solution. Along the way we also very strongly want to define semantics of "ref" in such a way that makes unsafe escapes impossible. These two features are related.

Wouldn't it be nice if such thing would be settled BEFORE breaking quite a lot of code when changing this behavior in 2.061 ?
Jan 26 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Saturday, 26 January 2013 at 17:02:40 UTC, deadalnix wrote:
 On Saturday, 26 January 2013 at 16:27:04 UTC, Andrei 
 Alexandrescu wrote:
 On 1/26/13 6:03 AM, Namespace wrote:
 In relation to this post:
 http://forum.dlang.org/thread/ssiulznvtkmfkimmatpk forum.dlang.org?page=5#post-knnghuzbzqddaqcjtvch:40forum.dlang.org

 I hereby open up again the discussion about auto ref.
 There are only some questions: Will auto ref be implemented 
 in the near
 future or not?

Yes. We are actively looking into a complete solution. Along the way we also very strongly want to define semantics of "ref" in such a way that makes unsafe escapes impossible. These two features are related.

Wouldn't it be nice if such thing would be settled BEFORE breaking quite a lot of code when changing this behavior in 2.061 ?

Absolute agreement. While it is true that structs are not lvalues​​, but to fix this known bug, without implement a solution for rvalue references was a really bad idea. This bug was so long tolerated because we hadn't a solution for rvalue references. So it would be good to know, why it was fixed this time, although we have still no rvalue refs.
Jan 26 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, January 26, 2013 17:51:23 Namespace wrote:
 That's good to know. But can you estimate _when_ it will be
 implemented or with which version? That would be very informative.

Things generally just don't work that way around here. They get done when they get done. And often some of the more important stuff takes a while, because it takes a while to get the design sorted out and implemented (especially if Walter is the one to implement it). So, much as it might be nice to have a roadmap saying when something is expected to be done, that pretty much never happens. - Jonathan M Davis
Jan 26 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Saturday, 26 January 2013 at 19:08:20 UTC, Jonathan M Davis 
wrote:
 On Saturday, January 26, 2013 17:51:23 Namespace wrote:
 That's good to know. But can you estimate _when_ it will be
 implemented or with which version? That would be very 
 informative.

Things generally just don't work that way around here. They get done when they get done. And often some of the more important stuff takes a while, because it takes a while to get the design sorted out and implemented (especially if Walter is the one to implement it). So, much as it might be nice to have a roadmap saying when something is expected to be done, that pretty much never happens. - Jonathan M Davis

And why? For special cases like this it could be helpfull and it is IMO possible. You have the pull and know what's went wrong with it (it breaks unittests). So you could say, how long it takes, until it is ready to merge. Another proposal, that I've suggested in another thread, would be to merge some "placeholder" pull which fix the problem until the official solution is implemented. I thought about this pull: https://github.com/D-Programming-Language/dmd/pull/1428 It is ready for merging and usage. This pull adds functionality for non-template auto refs but it doesn't change the (template) auto ref functionality in general, as Kenjis pull does.
Jan 26 2013
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, January 26, 2013 20:25:15 Namespace wrote:
 On Saturday, 26 January 2013 at 19:08:20 UTC, Jonathan M Davis
 
 wrote:
 On Saturday, January 26, 2013 17:51:23 Namespace wrote:
 That's good to know. But can you estimate _when_ it will be
 implemented or with which version? That would be very
 informative.

Things generally just don't work that way around here. They get done when they get done. And often some of the more important stuff takes a while, because it takes a while to get the design sorted out and implemented (especially if Walter is the one to implement it). So, much as it might be nice to have a roadmap saying when something is expected to be done, that pretty much never happens. - Jonathan M Davis

And why? For special cases like this it could be helpfull and it is IMO possible. You have the pull and know what's went wrong with it (it breaks unittests). So you could say, how long it takes, until it is ready to merge. Another proposal, that I've suggested in another thread, would be to merge some "placeholder" pull which fix the problem until the official solution is implemented. I thought about this pull: https://github.com/D-Programming-Language/dmd/pull/1428 It is ready for merging and usage. This pull adds functionality for non-template auto refs but it doesn't change the (template) auto ref functionality in general, as Kenjis pull does.

If we add a feature as a temporary measure and then remove it later, we're likely to end up breaking code when it's removed. It's not clear what the ultimate solution is going to be, particularly since Andrei is looking to fix refs in general (and based on previous discussions on this, I believe that Walter is looking to do the same), the solution could be more complicated. I don't know what they're going to do with it. But I'd be very surprised if anything were merged in to solve the problem before they've decided what they want to do. You seem to be in a big hurry to have this problem solved, but very little moves at that kind of pace around here, even if it's very important. If it were simply a bug fix, then someone (including you) could hop in, sort it out, and submit a fix, and it might get merged in fairly quickly (though the rate at which even straightforward pull requests gets merged in varies considerably). But this isn't just a bug fix. It affects the fundamental design of a portion of the language, which means that a design needs to be presented that satisfies both Walter and Andrei. Changes like that just don't happen quickly. And Andrei and Walter have some very definitive ideas about what they want to be able to guarantee with ref and safe, and doing that isn't easy. I don't expect that any solution to this will be merged in until they've agreed upon a solution. And I have no idea how long that will take. It sounds like Andrei is treating it as a relatively high priority for himself to sort out the problem, but he's a very busy fellow, and pretty much anything that requires a lot of work on his part tends to take a while as a result. So, while I can understand your frustration (and on some level share it), on an issue like this, you're just going to have to be patient. Making a big deal about it may get it to happen faster by bringing more attention to it, but it's still not going to be as simple as just merging a pull request, not with an issue like this. - Jonathan M Davis
Jan 26 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/26/13 9:28 PM, Era Scarecrow wrote:
 Having ref accept rValues seems like a bad idea. If the source is
 const/immutable then it might be allowed, but more likely temporaries
 will be made for convertion from rValues to lValues, then passing off
 the temporaries. The temporaries to work right likely need to be at the
 top-most scope of whatever function you happen to be in; Beyond that I'm
 not sure how else the auto ref could be implemented safely.

One simple matter that has been discussed here, which I've hit only yesterday in a script was: string lines; ... auto r = regex(...); auto m = lines.match(r); // Get rid of the whole match m.captures.popFront(); // This should be the first actual capture auto s = m.captures.front; The problem here is m.captures returns an rvalue. In turn that rvalue is bound (arguably incorrectly) to the reference "this" in the call to the member function popFront(). The method pops the front off the temporary, leaving the original intact. The subsequent invocation m.capture returns the value anew. This issue is a combination of properties that return rvalues with the current (too liberal IMHO) binding of rvalues to temporaries. The latter has been a design tidbit inherited from C++, and it's been in D for a long time. Andrei
Jan 27 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/27/13 8:05 AM, deadalnix wrote:
 It seems here that captures provide you a new copy every time. why not
 after all ? What is the problem here ?

The property, which is intended to behave as a field as much as possible, in this case continues to look like a field but doesn't act like one. That means that switching transparently between a field and a property (the holy grail of good properties) will silently break code.
 BTW, unless you create a temporary storage, you can't call any method on
 a struct. This is why in the first place struct literal MUST have a
 storage (so it make sense to bind them to ref).

I don't have your definition of "storage". Andrei
Jan 27 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/27/13 9:30 AM, deadalnix wrote:
 On Sunday, 27 January 2013 at 14:09:17 UTC, Andrei Alexandrescu wrote:
 On 1/27/13 8:05 AM, deadalnix wrote:
 It seems here that captures provide you a new copy every time. why not
 after all ? What is the problem here ?

The property, which is intended to behave as a field as much as possible, in this case continues to look like a field but doesn't act like one. That means that switching transparently between a field and a property (the holy grail of good properties) will silently break code.

OK, I understand. Do you suggest that calling function on rvalue should be prevented ?

It's part of the many interactions that must be minded in defining properties and binding rvalues to ref. Andrei
Jan 27 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 If we add a feature as a temporary measure and then remove it 
 later, we're
 likely to end up breaking code when it's removed.

currently very well for template functions and the pull I suggest adds the same functionality for normal functions. So if one day an official solution is there, nothing will be broken. The solutions code has (maybe) another implementation but it don't touch auto ref functionality in general.
 You seem to be in a big hurry to have this problem solved, but 
 very little
 moves at that kind of pace around here, even if it's very 
 important.

thing that every language should have.
 So, while I can understand your frustration (and on some level 
 share it), on
 an issue like this, you're just going to have to be patient. 
 Making a big deal
 about it may get it to happen faster by bringing more attention 
 to it, but
 it's still not going to be as simple as just merging a pull 
 request, not with
 an issue like this.

 - Jonathan M Davis

Good to hear that I'm not alone with this.
Jan 26 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, January 27, 2013 01:32:07 Namespace wrote:
 If we add a feature as a temporary measure and then remove it
 later, we're
 likely to end up breaking code when it's removed.

No, as far as I can see this don't happend. auto ref works currently very well for template functions and the pull I suggest adds the same functionality for normal functions. So if one day an official solution is there, nothing will be broken. The solutions code has (maybe) another implementation but it don't touch auto ref functionality in general.

But it may not even end up being the case that using auto ref on non-templated functions is the solution. It may end up being something else entirely. Ignoring safety issues, it seems to me like it would be the most straightforward solution, but there are safety issues with ref in general that need to be addressed, and Andrei intends to address them as part of whatever happens with auto ref. That mean that auto ref gets used for non- templated functions, or it could mean something very different. I don't know what exactly the solution that Andrei is working on could entail. For all I know, it'll involve letting ref in general accept rvalues (much as I tihnk that that's a horrible idea, it _has_ been suggested before). So, without a clear idea of what we're going to want to do, merging in the pull request which makes auto ref work for non-templated functions is a bad idea. It could ultimately end up being fine, or it could end up breaking more code when the real solution gets implemented. - Jonathan M Davis
Jan 26 2013
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Sunday, 27 January 2013 at 01:23:18 UTC, Jonathan M Davis 
wrote:

 But it may not even end up being the case that using auto ref 
 on non-templated functions is the solution. It may end up being 
 something else entirely. Ignoring  safety issues, it seems to 
 me like it would be the most straightforward solution, but 
 there are  safety issues with ref in general that need to be 
 addressed, and Andrei intends to address them as part of 
 whatever happens with auto ref. That mean that auto ref gets 
 used for non- templated functions, or it could mean something 
 very different. I don't know what exactly the solution that 
 Andrei is working on could entail. For all I know, it'll 
 involve letting ref in general accept rvalues (much as I tihnk 
 that that's a horrible idea, it _has_ been suggested before). 
 So, without a clear idea of what we're going to want to do, 
 merging in the pull request which makes auto ref work for 
 non-templated functions is a bad idea. It could ultimately end 
 up being fine, or it could end up breaking more code when the 
 real solution gets implemented.

Having ref accept rValues seems like a bad idea. If the source is const/immutable then it might be allowed, but more likely temporaries will be made for convertion from rValues to lValues, then passing off the temporaries. The temporaries to work right likely need to be at the top-most scope of whatever function you happen to be in; Beyond that I'm not sure how else the auto ref could be implemented safely.
Jan 26 2013
prev sibling next sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 01/26/2013 03:03 AM, Namespace wrote:

 with dmd 2.061 structs aren't lvalues anymore.

You mean, temporary struct objects are not lvalues anymore. Ali
Jan 26 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 27 January 2013 at 02:28:26 UTC, Era Scarecrow wrote:
  Having ref accept rValues seems like a bad idea. If the source 
 is const/immutable then it might be allowed, but more likely 
 temporaries will be made for convertion from rValues to 
 lValues, then passing off the temporaries. The temporaries to 
 work right likely need to be at the top-most scope of whatever 
 function you happen to be in; Beyond that I'm not sure how else 
 the auto ref could be implemented safely.

I have yet to see an instance of such problem in real life, but quite frankly, I tired to argue.
Jan 26 2013
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Sunday, 27 January 2013 at 04:38:44 UTC, deadalnix wrote:
 On Sunday, 27 January 2013 at 02:28:26 UTC, Era Scarecrow wrote:
 Having ref accept rValues seems like a bad idea. If the source 
 is const/immutable then it might be allowed, but more likely 
 temporaries will be made for convertion from rValues to 
 lValues, then passing off the temporaries. The temporaries to 
 work right likely need to be at the top-most scope of whatever 
 function you happen to be in; Beyond that I'm not sure how 
 else the auto ref could be implemented safely.

I have yet to see an instance of such problem in real life, but quite frankly, I tired to argue.

I would have thought it was obvious. I have done before where all my work was done from a ref. Now being that i wouldn't want to duplicate my code twice, the non-ref simply forwards to the ref. auto ref may automate removing the need to explicitly forward temporaries or make them yourself; Kinda like how scope makes things easier. For some reason opCmp is coming to mind as a good example. struct S { //90%+ of the time this will be called, //so without needing to do overhead we will do our compare. int opCmp(ref S rhs); //why duplicate code? Just forward to ref int opCmp(S rhs) { return this.opCmp(rhs); } } S l, r; assert(l >= r); //uses ref assert(l >= S()); //uses non-ref, forwards to ref I remember I came up with a good reason why the temporary should be added to the outer scope, but the reason escapes me right now. But as I'm thinking about the other half having ref accept rValues, I would see that acceptable if the following qualified. 1) Must be 'const ref' or 'immutable ref', no changes means likely no special handling. 2) No special postblit or opAssign operations and/or 3) The rValue in question is a POD (Plain Old Data) Since likely the rValue would have to be statically known at compile-time so it could create a read-only instance in the data portion, then refer to it. By itself it seems fairly simple to add in; but I'm honestly not sure, not being able to tell them apart when you need to seems like an annoyance, likely that C++'s been dealing with.
Jan 26 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 27 January 2013 at 06:13:25 UTC, Era Scarecrow wrote:
 On Sunday, 27 January 2013 at 04:38:44 UTC, deadalnix wrote:
 On Sunday, 27 January 2013 at 02:28:26 UTC, Era Scarecrow 
 wrote:
 Having ref accept rValues seems like a bad idea. If the 
 source is const/immutable then it might be allowed, but more 
 likely temporaries will be made for convertion from rValues 
 to lValues, then passing off the temporaries. The temporaries 
 to work right likely need to be at the top-most scope of 
 whatever function you happen to be in; Beyond that I'm not 
 sure how else the auto ref could be implemented safely.

I have yet to see an instance of such problem in real life, but quite frankly, I tired to argue.

I would have thought it was obvious. I have done before where all my work was done from a ref. Now being that i wouldn't want to duplicate my code twice, the non-ref simply forwards to the ref. auto ref may automate removing the need to explicitly forward temporaries or make them yourself; Kinda like how scope makes things easier.

You completely fail to address the point raised. Back on the point, quoting « Having ref accept rValues seems like a bad idea. ». D accepted it for ages, some language accept it by design (java for instance). Now can someone show me the code ?
Jan 26 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, January 27, 2013 07:28:24 deadalnix wrote:
 Back on the point, quoting =C2=AB Having ref accept rValues seems lik=

 a bad idea. =C2=BB. D accepted it for ages, some language accept it b=

 design (java for instance).
=20
 Now can someone show me the code ?

D's ref has never accepted rvalues. Rather, struct literals were incorr= ectly=20 treated as lvalues. And Java has nothing like ref whatsoever. It has=20= references like D's references, which are managed pointers, but that's=20= completely different. - Jonathan M Davis
Jan 26 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 But it may not even end up being the case that using auto ref 
 on non-templated
 functions is the solution. It may end up being something else 
 entirely.
 Ignoring  safety issues, it seems to me like it would be the 
 most
 straightforward solution, but there are  safety issues with ref 
 in general
 that need to be addressed, and Andrei intends to address them 
 as part of
 whatever happens with auto ref. That mean that auto ref gets 
 used for non-
 templated functions, or it could mean something very different. 
 I don't know
 what exactly the solution that Andrei is working on could 
 entail. For all I
 know, it'll involve letting ref in general accept rvalues (much 
 as I tihnk
 that that's a horrible idea, it _has_ been suggested before). 
 So, without a
 clear idea of what we're going to want to do, merging in the 
 pull request
 which makes auto ref work for non-templated functions is a bad 
 idea. It could
 ultimately end up being fine, or it could end up breaking more 
 code when the
 real solution gets implemented.

 - Jonathan M Davis

Ehh, so if auto ref won't be the solution, we then have auto ref for template functions and another solution for non-ref functions? I don't think that that is a smart idea and that it would be a kind of inconsistent.
Jan 27 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, January 27, 2013 10:47:42 Namespace wrote:
 Ehh, so if auto ref won't be the solution, we then have auto ref
 for template functions and another solution for non-ref
 functions? I don't think that that is a smart idea and that it
 would be a kind of inconsistent.

I don't know what solution we're going to get. And auto ref for templates actually serves another purpose other than trying to avoid unnecessary copies in that it apparently helps with attempts at perfect forwarding (though I don't remember the details, since I haven't used it for that). It's an accidental benefit of auto ref (the whole idea behind it in the first place was to deal with the const& problem), but it means that auto ref on templated functions is valuable regardless of what happens with non-templated functions. And has been pointed out, the proposed solution for auto ref and non-templated functions (that is, have the compiler create a variable to assign an rvalue to and then pass that to the function) would arguably be desirable with templated functions as well (in order to reduce code bloat), so it's arguably better to pick something other than auto ref so that it can be used for both templated and non-templated functions. Regardless, I can't comment on what the final solution is going to be, because I don't know what it's going to be. And moving forward with an implementation that we may just throw away would be a mistake. So, we're just going to have to wait for Andrei to finish his proposal so that it can be discussed and hopefully implemented once it's been fully vetted and fleshed out. - Jonathan M Davis
Jan 27 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
I didn't know. I thought auto ref would be the only solutions for 
non-template functions.
But then I think we must wait for 2 or 3 versions. With this 
background knowledge I will write my code twice, with and without 
ref. Thank you.
Jan 27 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 27 January 2013 at 12:58:17 UTC, Andrei Alexandrescu 
wrote:
 On 1/26/13 9:28 PM, Era Scarecrow wrote:
 Having ref accept rValues seems like a bad idea. If the source 
 is
 const/immutable then it might be allowed, but more likely 
 temporaries
 will be made for convertion from rValues to lValues, then 
 passing off
 the temporaries. The temporaries to work right likely need to 
 be at the
 top-most scope of whatever function you happen to be in; 
 Beyond that I'm
 not sure how else the auto ref could be implemented safely.

One simple matter that has been discussed here, which I've hit only yesterday in a script was: string lines; ... auto r = regex(...); auto m = lines.match(r); // Get rid of the whole match m.captures.popFront(); // This should be the first actual capture auto s = m.captures.front; The problem here is m.captures returns an rvalue. In turn that rvalue is bound (arguably incorrectly) to the reference "this" in the call to the member function popFront(). The method pops the front off the temporary, leaving the original intact. The subsequent invocation m.capture returns the value anew. This issue is a combination of properties that return rvalues with the current (too liberal IMHO) binding of rvalues to temporaries. The latter has been a design tidbit inherited from C++, and it's been in D for a long time.

I think that it is unclear what should happen when a range is copied. This is an issue a ran into quite often. It seems here that captures provide you a new copy every time. why not after all ? What is the problem here ? BTW, unless you create a temporary storage, you can't call any method on a struct. This is why in the first place struct literal MUST have a storage (so it make sense to bind them to ref).
Jan 27 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Sunday, 27 January 2013 at 14:09:17 UTC, Andrei Alexandrescu 
wrote:
 The property, which is intended to behave as a field as much as 
 possible, in this case continues to look like a field but 
 doesn't act like one. That means that switching transparently 
 between a field and a property (the holy grail of good 
 properties) will silently break code.

Some other discussion in property topic made me wonder if enforcing const on getter non-ref return values makes sense.
Jan 27 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 27 January 2013 at 14:09:17 UTC, Andrei Alexandrescu 
wrote:
 On 1/27/13 8:05 AM, deadalnix wrote:
 It seems here that captures provide you a new copy every time. 
 why not
 after all ? What is the problem here ?

The property, which is intended to behave as a field as much as possible, in this case continues to look like a field but doesn't act like one. That means that switching transparently between a field and a property (the holy grail of good properties) will silently break code.

OK, I understand. Do you suggest that calling function on rvalue should be prevented ?
 BTW, unless you create a temporary storage, you can't call any 
 method on
 a struct. This is why in the first place struct literal MUST 
 have a
 storage (so it make sense to bind them to ref).

I don't have your definition of "storage".

Some piece of memory to store the struct in. Depending on the ABI that is not guaranteed that an rvalue has a storage.
Jan 27 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Sunday, 27 January 2013 at 10:35:34 UTC, Namespace wrote:
 I didn't know. I thought auto ref would be the only solutions 
 for non-template functions.
 But then I think we must wait for 2 or 3 versions. With this 
 background knowledge I will write my code twice, with and 
 without ref. Thank you.

Bug 9410 makes it even worse to handle struct as rvalues _and_ lvalues: http://forum.dlang.org/thread/bug-9410-3 http.d.puremagic.com%2Fissues%2F#post-ke3aeh:242i00:241:40digitalmars.com As I said before: D isn't ready for real production. This is the sad truth.
Jan 27 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Sunday, 27 January 2013 at 14:54:26 UTC, Namespace wrote:
 On Sunday, 27 January 2013 at 10:35:34 UTC, Namespace wrote:
 I didn't know. I thought auto ref would be the only solutions 
 for non-template functions.
 But then I think we must wait for 2 or 3 versions. With this 
 background knowledge I will write my code twice, with and 
 without ref. Thank you.

Bug 9410 makes it even worse to handle struct as rvalues _and_ lvalues: http://forum.dlang.org/thread/bug-9410-3 http.d.puremagic.com%2Fissues%2F#post-ke3aeh:242i00:241:40digitalmars.com As I said before: D isn't ready for real production. This is the sad truth.

It's fixed. Kenji is the best. :) Andrei: It would be great (And I would be very glad) if you keep us up to date with your plan about const&.
Jan 28 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
And before I forget, can I also suggest a syntax?
I would love 'ref&'. ;) It's pretty short and smart.
Jan 28 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
The next beta is on the way and that will be the fourth (or 
fifth?) version, since the first discussions (I've found) about 
rvalue refs.
So if you have any plans to deal with this, it would be nice if 
you tell it us.
It would also be good to know, if your ideas goes towards auto 
ref, means function bloat, or if a tempory variable is created 
(as in C++, I think) by the compiler and will passed to the ref 
function.
Or if you have another idea, just this.

I sincerely hope that this thread / post is not ignored. It's 
still an absolutely important issue.
Feb 02 2013
prev sibling next sibling parent "Lee Braiden" <leebraid gmail.com> writes:
On Saturday, 26 January 2013 at 19:08:20 UTC, Jonathan M Davis 
wrote:
 On Saturday, January 26, 2013 17:51:23 Namespace wrote:
 That's good to know. But can you estimate _when_ it will be
 implemented or with which version? That would be very 
 informative.

Things generally just don't work that way around here. They get done when they get done. And often some of the more important stuff takes a while, because it takes a while to get the design sorted out and implemented (especially if Walter is the one to implement it). So, much as it might be nice to have a roadmap saying when something is expected to be done, that pretty much never happens. - Jonathan M Davis

I would suggest that it should work this way, and that maybe this should be part of the new process focus. This isn't intended to be demanding -- it could be fairly simple to provide SOME guide to timeframes. For example, with redmine, you can attach issues to milestones/releases, and give an estimate of time involved. Redmine will then project time to finish that milestone, drawing a nice chart of issues closed vs. open vs. total time. If that milestone is three releases away, not being actively worked on, and you have two milestones between, with time estimates for each, then users can STILL see a reasonable timeframe for things, even if it's still updating.
Feb 06 2013
prev sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 I would suggest that it should work this way, and that maybe 
 this should be part of the new process focus.

 This isn't intended to be demanding -- it could be fairly 
 simple to provide SOME guide to timeframes.  For example, with 
 redmine, you can attach issues to milestones/releases, and give 
 an estimate of time involved.  Redmine will then project time 
 to finish that milestone, drawing a nice chart of issues closed 
 vs. open vs. total time.  If that milestone is three releases 
 away, not being actively worked on, and you have two milestones 
 between, with time estimates for each, then users can STILL see 
 a reasonable timeframe for things, even if it's still updating.

Obviously, no one is interested in such a thing. ;) But I like the Idea.
Feb 10 2013