Issue 1974 - What's your opinion?

Exil Exil at gmall.com
Fri Oct 25 17:49:15 UTC 2019


On Friday, 25 October 2019 at 01:20:02 UTC, kinke wrote:
> On Thursday, 24 October 2019 at 08:02:28 UTC, RazvanN wrote:
>> What are your thoughts on this? Should be close the issue as 
>> an invalid one?
>
> I'm clearly in favor of the filed issue, i.e., see it as valid. 
> This is for consistency with primitive types, and lvalue-ness 
> is IMO a clear intrinsic requirement for a (bin)assign 
> operator's left hand side:
>
> ```
> struct S { int i; }
>
> struct O
> {
>     int i;
>     void opOpAssign(string op)(int) {}
> }
>
> T make(T)() { return cast(T) 1; }
>
> void foo()
> {
>     make!int() += 2; // Error: `make()` is not an lvalue and 
> cannot be modified
>     make!S() += 2;   // Error: `make()` is not an lvalue and 
> cannot be modified
>     make!O() += 2;   // compiles
> }
> ```
>
> Allowing rvalues for an explicit opOpAssign!"+" call is IMO 
> fine, but not when using the operator, as that's just a leaking 
> implementation detail.

The core problem with this is that you can't distinguish rvalue 
and lvalues for methods. It's a similar problem to this: 
https://issues.dlang.org/show_bug.cgi?id=19507

And you can still make calls `make!S().i += 2` or 
`make!S().modifyingFoo()`. There's no point putting a band aid on 
the problem for this one particular case.


>     make!S() += 2;   // Error: `make()` is not an lvalue and 
> cannot be modified

That error message is deceptive. You can't use "+=" with S either 
way. This would be a more correct error message:

     S s;
     s += 2; // Error: s is not a scalar, it is a S

Not the best error message either for the problem. Would make 
more sense if it told the user the "+=" isn't overridden for S.


More information about the Digitalmars-d mailing list