2011/9/5 Don Clugston <dclugston at googlemail.com>:
> I've never been able to get that to work. Although you can get those two to work, it fails in other cases. Eg, as in the code below. Have you been able to do this successfully?
>
[snip]
> ? assert(s==s2); // fails, ambiguous
[snip]

It is a bug part of issue 5889, and I know how to fix it.
see https://github.com/D-Programming-Language/dmd/pull/41/files

TypeStruct::defaultInit() returns the expression of S.init, but it is lvalue. so the ref-nonref resolution was failed against struct type in FuncDeclaration::leastAsSpecialized.

The changes of dmd/pull/41:
- Use TypeStruct::defaultInitLiteal() (returns S()) instead of
TypeStruct::defaultInit() in FuncDeclaraton::leastAsSpecialized()
- Change S() from lvalue to rvalue
  <- Remove StructLiteralExp::isLvalue
  <- Wrap CallExp (S __ctmp = 0; __ctmp).this(ctorargs...) into
StructContructExp, and make it rvalue

----

I think string literal shoud be rvalue, like array literal (e.g. [e0,
e1, ..., eN]).
And also struct literal should be rvalue.
The passable to a ref parameter for the two kind of literals is
definitely bug to me.

Kenji Hara

2011/9/5 Jonathan M Davis <jmdavisProg at gmx.com>:
> On Monday, September 05, 2011 11:20:57 Don Clugston wrote:
>> I've never been able to get that to work. Although you can get those two to work, it fails in other cases. Eg, as in the code below. Have you been able to do this successfully?
>>
>> [snip]
>
> Probably not. I don't think that I've tried though. I'm not sure how often I've used immutable structs in a context that ended up using an equality check.
>
> Regardless, opEquals obviously needs to be sorted out. You shouldn't need two definitions like that to get it to work even if they did work in all cases.

I think we need to define tow opEquals, const bool opEquals(const S
rhs) and const bool opEquals(const ref S rhs).
But rvalue version is automatically builded by compiler, like follows:

const bool opEquals(const S rhs) {
  return this.opEquals(rhs);  // run lvalue version
}

So we don't need to *write* two opEquals still.

Kenji Hara

On 9/5/11 2:34 AM, Walter Bright wrote:
>
>
> On 9/4/2011 10:54 PM, Jonathan M Davis wrote:
>>
>> It's a bug in dmd. string literals aren't lvalues
>
> Yes, they are, because one can take the address of them.
>
> What they are not are *modifiable* lvalues.

How can we express that in the type system?

Andrei

This remains a bug in the compiler. One opEquals signature should suffice, namely:

bool opEquals(const S rhs) const;

If someone wants to optimize away a copy when an lvalue is in the rhs position, they could add the overload:

bool opEquals(ref const S rhs) const;

But the second should be optional.

One more thing - the compiler should _not_ require these signatures. It should let the user define them as they wish and simply limit itself to translating a == b to a.opEquals(b).


Andrei

On 9/5/11 6:31 AM, kenji hara wrote:
> 2011/9/5 Jonathan M Davis<jmdavisProg at gmx.com>:
>> On Monday, September 05, 2011 11:20:57 Don Clugston wrote:
>>> I've never been able to get that to work. Although you can get those two to work, it fails in other cases. Eg, as in the code below. Have you been able to do this successfully?
>>>
>>> [snip]
>>
>> Probably not. I don't think that I've tried though. I'm not sure how often I've used immutable structs in a context that ended up using an equality check.
>>
>> Regardless, opEquals obviously needs to be sorted out. You shouldn't need two definitions like that to get it to work even if they did work in all cases.
>
> I think we need to define tow opEquals, const bool opEquals(const S
> rhs) and const bool opEquals(const ref S rhs).
> But rvalue version is automatically builded by compiler, like follows:
>
> const bool opEquals(const S rhs) {
>    return this.opEquals(rhs);  // run lvalue version
> }
>
> So we don't need to *write* two opEquals still.
>
> Kenji Hara
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Le 2011-09-05 ? 8:42, Andrei Alexandrescu a ?crit :

> On 9/5/11 2:34 AM, Walter Bright wrote:
>> 
>> On 9/4/2011 10:54 PM, Jonathan M Davis wrote:
>>> 
>>> It's a bug in dmd. string literals aren't lvalues
>> 
>> Yes, they are, because one can take the address of them.
>> 
>> What they are not are *modifiable* lvalues.
> 
> How can we express that in the type system?

Actually if you see the string literal "hello" as an immutable(char[5]) inside the resulting binary, then you can take its address so it is a rvalue.

But that's a static array. If you implicitly convert it to a dynamic array, of type immutable(char)[], this dynamic array is a temporary rvalue and you shouldn't be able to take its address.

So do we want static arrays or dynamic arrays as string literals? Static arrays can be lvalues, dynamic arrays cannot.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

We decided a while ago that it's best for string literals to be dynamic arrays, not static. This came along with the switch to pass-by-value of static arrays. The problem was templates would end up copying string literals.

Andrei

On 9/5/11 9:28 AM, Michel Fortin wrote:
> Le 2011-09-05 ? 8:42, Andrei Alexandrescu a ?crit :
>
>> On 9/5/11 2:34 AM, Walter Bright wrote:
>>>
>>> On 9/4/2011 10:54 PM, Jonathan M Davis wrote:
>>>>
>>>> It's a bug in dmd. string literals aren't lvalues
>>>
>>> Yes, they are, because one can take the address of them.
>>>
>>> What they are not are *modifiable* lvalues.
>>
>> How can we express that in the type system?
>
> Actually if you see the string literal "hello" as an immutable(char[5]) inside the resulting binary, then you can take its address so it is a rvalue.
>
> But that's a static array. If you implicitly convert it to a dynamic array, of type immutable(char)[], this dynamic array is a temporary rvalue and you shouldn't be able to take its address.
>
> So do we want static arrays or dynamic arrays as string literals? Static arrays can be lvalues, dynamic arrays cannot.
>