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?

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 reply 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
next sibling parent reply "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
parent reply 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
next sibling parent reply "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
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 "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.


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.

 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.


Yes, in my opinion this feature is a very important and basic 
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
parent reply 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
next sibling parent reply "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
next sibling parent reply "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
parent reply "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
parent reply "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
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=


e

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


y

 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 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 "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
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
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 parent reply "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
parent reply 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
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 parent reply "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
parent reply 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
parent reply "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
parent reply "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
parent reply "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
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 parent reply "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
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
prev sibling parent reply "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
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 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