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).

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

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.

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.

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

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.

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&.

And before I forget, can I also suggest a syntax?
I would love 'ref&'. ;) It's pretty short and smart.

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.

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.