I suppose I should have already known this, but I was surprised today to find that this didn't work:

    auto val = x + seconds(y);

    Duration seconds(long x) { ... }

    struct Duration {
        Duration opOpAssign(string op)( ref const(Duration) other ) { ... }
    }

With the error:

    Error: function core.time.Duration.opOpAssign!("+").opOpAssign (ref const(Duration) other) is not callable using argument types (Duration)
    src/core/sync/config.d(59): Error: seconds(y) is not an lvalue

Someone please tell me that this is a bug and that it will be fixed soon.  A quick search on the bug tracker didn't turn up anything.

An rvalue should not bind to a reference. I think Duration is small enough to pass by value. If not, we need to wait for "auto ref" to be fixed.

Andrei

On 12/10/10 11:51 AM, Sean Kelly wrote:
> I suppose I should have already known this, but I was surprised today to find that this didn't work:
>
>      auto val = x + seconds(y);
>
>      Duration seconds(long x) { ... }
>
>      struct Duration {
>          Duration opOpAssign(string op)( ref const(Duration) other ) { ... }
>      }
>
> With the error:
>
>      Error: function core.time.Duration.opOpAssign!("+").opOpAssign (ref const(Duration) other) is not callable using argument types (Duration)
>      src/core/sync/config.d(59): Error: seconds(y) is not an lvalue
>
> Someone please tell me that this is a bug and that it will be fixed soon.  A quick search on the bug tracker didn't turn up anything.
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

I'm sure there was a discussion about this.  Why the divergence from C++ here?  I'll change the methods to accept Duration by value--it only contains a long.  "auto ref" is intended to solve a different problem, so I won't be using it here.

On Dec 10, 2010, at 12:28 PM, Andrei Alexandrescu wrote:

> An rvalue should not bind to a reference. I think Duration is small enough to pass by value. If not, we need to wait for "auto ref" to be fixed.
> 
> Andrei
> 
> On 12/10/10 11:51 AM, Sean Kelly wrote:
>> I suppose I should have already known this, but I was surprised today to find that this didn't work:
>> 
>>     auto val = x + seconds(y);
>> 
>>     Duration seconds(long x) { ... }
>> 
>>     struct Duration {
>>         Duration opOpAssign(string op)( ref const(Duration) other ) { ... }
>>     }
>> 
>> With the error:
>> 
>>     Error: function core.time.Duration.opOpAssign!("+").opOpAssign (ref const(Duration) other) is not callable using argument types (Duration)
>>     src/core/sync/config.d(59): Error: seconds(y) is not an lvalue
>> 
>> Someone please tell me that this is a bug and that it will be fixed soon.  A quick search on the bug tracker didn't turn up anything.
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

Um... problem:

    Error: function core.time.Duration.opEquals type signature should be const bool(ref const(Duration)) not const bool(Duration other)

I'm being forced to define a method that doesn't accept temporaries?  Not a huge problem since I don't use opEquals very often, but...

On Dec 10, 2010, at 2:13 PM, Sean Kelly wrote:

> I'm sure there was a discussion about this.  Why the divergence from C++ here?  I'll change the methods to accept Duration by value--it only contains a long.  "auto ref" is intended to solve a different problem, so I won't be using it here.
> 
> On Dec 10, 2010, at 12:28 PM, Andrei Alexandrescu wrote:
> 
>> An rvalue should not bind to a reference. I think Duration is small enough to pass by value. If not, we need to wait for "auto ref" to be fixed.
>> 
>> Andrei
>> 
>> On 12/10/10 11:51 AM, Sean Kelly wrote:
>>> I suppose I should have already known this, but I was surprised today to find that this didn't work:
>>> 
>>>    auto val = x + seconds(y);
>>> 
>>>    Duration seconds(long x) { ... }
>>> 
>>>    struct Duration {
>>>        Duration opOpAssign(string op)( ref const(Duration) other ) { ... }
>>>    }
>>> 
>>> With the error:
>>> 
>>>    Error: function core.time.Duration.opOpAssign!("+").opOpAssign (ref const(Duration) other) is not callable using argument types (Duration)
>>>    src/core/sync/config.d(59): Error: seconds(y) is not an lvalue
>>> 
>>> Someone please tell me that this is a bug and that it will be fixed soon.  A quick search on the bug tracker didn't turn up anything.
>>> _______________________________________________
>>> dmd-internals mailing list
>>> dmd-internals at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
> 
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

This matter is discussed now in the newsgroup.

Andrei

On 12/10/10 2:13 PM, Sean Kelly wrote:
> I'm sure there was a discussion about this.  Why the divergence from C++ here?  I'll change the methods to accept Duration by value--it only contains a long.  "auto ref" is intended to solve a different problem, so I won't be using it here.
>
> On Dec 10, 2010, at 12:28 PM, Andrei Alexandrescu wrote:
>
>> An rvalue should not bind to a reference. I think Duration is small enough to pass by value. If not, we need to wait for "auto ref" to be fixed.
>>
>> Andrei
>>
>> On 12/10/10 11:51 AM, Sean Kelly wrote:
>>> I suppose I should have already known this, but I was surprised today to find that this didn't work:
>>>
>>>      auto val = x + seconds(y);
>>>
>>>      Duration seconds(long x) { ... }
>>>
>>>      struct Duration {
>>>          Duration opOpAssign(string op)( ref const(Duration) other ) { ... }
>>>      }
>>>
>>> With the error:
>>>
>>>      Error: function core.time.Duration.opOpAssign!("+").opOpAssign (ref const(Duration) other) is not callable using argument types (Duration)
>>>      src/core/sync/config.d(59): Error: seconds(y) is not an lvalue
>>>
>>> Someone please tell me that this is a bug and that it will be fixed soon.  A quick search on the bug tracker didn't turn up anything.
>>> _______________________________________________
>>> dmd-internals mailing list
>>> dmd-internals at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

Just saw the discussion.  I don't particularly like the use of "auto" for this, but the behavior makes sense.  I can't help feeling like it could be simplified somehow though :-p

On Dec 10, 2010, at 3:18 PM, Andrei Alexandrescu wrote:

> This matter is discussed now in the newsgroup.
> 
> Andrei
> 
> On 12/10/10 2:13 PM, Sean Kelly wrote:
>> I'm sure there was a discussion about this.  Why the divergence from C++ here?  I'll change the methods to accept Duration by value--it only contains a long.  "auto ref" is intended to solve a different problem, so I won't be using it here.
>> 
>> On Dec 10, 2010, at 12:28 PM, Andrei Alexandrescu wrote:
>> 
>>> An rvalue should not bind to a reference. I think Duration is small enough to pass by value. If not, we need to wait for "auto ref" to be fixed.
>>> 
>>> Andrei
>>> 
>>> On 12/10/10 11:51 AM, Sean Kelly wrote:
>>>> I suppose I should have already known this, but I was surprised today to find that this didn't work:
>>>> 
>>>>     auto val = x + seconds(y);
>>>> 
>>>>     Duration seconds(long x) { ... }
>>>> 
>>>>     struct Duration {
>>>>         Duration opOpAssign(string op)( ref const(Duration) other ) { ... }
>>>>     }
>>>> 
>>>> With the error:
>>>> 
>>>>     Error: function core.time.Duration.opOpAssign!("+").opOpAssign (ref const(Duration) other) is not callable using argument types (Duration)
>>>>     src/core/sync/config.d(59): Error: seconds(y) is not an lvalue
>>>> 
>>>> Someone please tell me that this is a bug and that it will be fixed soon.  A quick search on the bug tracker didn't turn up anything.
>>>> _______________________________________________
>>>> dmd-internals mailing list
>>>> dmd-internals at puremagic.com
>>>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>>> _______________________________________________
>>> dmd-internals mailing list
>>> dmd-internals at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>> 
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals

Ran into the same problem long ago when moving dcollections to D2.

Andrei opened a bug on this: http://d.puremagic.com/issues/show_bug.cgi?id=3659

Here's my rant on the NG :)

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=109239


-Steve



----- Original Message ----
> From: Sean Kelly <sean at invisibleduck.org>
> To: Discuss the internals of DMD <dmd-internals at puremagic.com>
> Sent: Fri, December 10, 2010 5:15:55 PM
> Subject: Re: [dmd-internals] ref const(T) doesn't accept struct temporaries?
> 
> Um... problem:
> 
>     Error: function core.time.Duration.opEquals  type signature should be const
>bool(ref const(Duration)) not const bool(Duration  other)
> 
> I'm being forced to define a method that doesn't accept  temporaries?  Not a
>huge problem since I don't use opEquals very often,  but...

Yeah, that;s the discussion I found :-)  I saw the other one too, but yours was more detailed.

What gets me about "auto ref" is that the "auto" here really has two purposes.  First, the function according to the questionably useful example:

auto ref T min(T)(auto ref T x, auto ref T y) {
    return x < y ? x : y;
}
int x = 1;
int y = min(x, 1)++;

I say questionably because I still doubt the need for passing the reference to the original value through in this case.  I'm sure there are examples justifying this, but the min() one doesn't cut it :-)

The other purpose is that it provides optimal performance in instances where the function may take both rvalues and lvalues and the function creator doesn't care that lvalues will be passed by ref (or const ref).  I can see "auto ref" and "auto const ref" being used all over the place "just in case," kind of like "register" was in C, which is not at all appealing.  I don't know what the answer is, but something about "auto ref" parameters just feels a bit clunky.

I also agree with Don about the use of "auto" rather than some other keyword, but I can see why it was chosen.

On Dec 13, 2010, at 6:04 AM, Steve Schveighoffer wrote:

> Ran into the same problem long ago when moving dcollections to D2.
> 
> Andrei opened a bug on this: http://d.puremagic.com/issues/show_bug.cgi?id=3659
> 
> Here's my rant on the NG :)
> 
> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=109239
> 
> 
> -Steve
> 
> 
> 
> ----- Original Message ----
>> From: Sean Kelly <sean at invisibleduck.org>
>> To: Discuss the internals of DMD <dmd-internals at puremagic.com>
>> Sent: Fri, December 10, 2010 5:15:55 PM
>> Subject: Re: [dmd-internals] ref const(T) doesn't accept struct temporaries?
>> 
>> Um... problem:
>> 
>>    Error: function core.time.Duration.opEquals  type signature should be const
>> bool(ref const(Duration)) not const bool(Duration  other)
>> 
>> I'm being forced to define a method that doesn't accept  temporaries?  Not a huge problem since I don't use opEquals very often,  but...
> 
> 
> 
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals