Thread overview
[Issue 23353] Add opCallAssign and opCallOpAssign
Sep 21, 2022
Bolpat
Sep 23, 2022
RazvanN
Oct 10, 2022
Bolpat
Dec 17, 2022
Iain Buclaw
September 21, 2022
https://issues.dlang.org/show_bug.cgi?id=23353

Bolpat <qs.il.paperinik@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |qs.il.paperinik@gmail.com

--
September 23, 2022
https://issues.dlang.org/show_bug.cgi?id=23353

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |razvan.nitu1305@gmail.com

--- Comment #1 from RazvanN <razvan.nitu1305@gmail.com> ---
Can you provide a case where this is useful and is not achievable by the current semantics? If opCall returns the a struct by ref and you also define an opAssign that should be achievable.

Usually, enhancement requests should be accompanied by a concrete use case where the lack of feature impedes a specific implementation. Otherwise, it is hard to make an argument for the addition of specific features.

--
October 10, 2022
https://issues.dlang.org/show_bug.cgi?id=23353

--- Comment #2 from Bolpat <qs.il.paperinik@gmail.com> ---
(In reply to RazvanN from comment #1)
> Can you provide a case where this is useful and is not achievable by the current semantics? If opCall returns the a struct by ref and you also define an opAssign that should be achievable.

It’s the same argument why properties have setter functions and why opIndexAssign exists. Any argument carries over immediately.

> Usually, enhancement requests should be accompanied by a concrete use case where the lack of feature impedes a specific implementation. Otherwise, it is hard to make an argument for the addition of specific features.

Effectively, if obj() returns a proxy type that mimics assignment by reference
(cf. C++ std::vector<bool>::reference) that type is weird. Most importantly, it
breaks meta-programming:

    auto x = obj(a, b);

does not work as intended. It is as if it were

    auto ptr = &obj(a, b);

if opCall returned by reference and x is as if *ptr.

In the past, @safe was an issue. Probably it is solved by DIP 1000, maybe I missed something.

--
December 17, 2022
https://issues.dlang.org/show_bug.cgi?id=23353

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

--