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