Comment #0 by qs.il.paperinik — 2022-09-21T14:52:28Z
The semantics of opCall and opIndex are very similar. They hook the same kind of syntactic expressions: obj(args) and obj[args]. However, opIndex is way more versatile because there are also opIndexAssign and opIndexOpAssign, which hook expressions like obj[args] = value. No such thing exists for opCall, i.e. hypothetical opCallAssign and opCallOpAssign, which hook obj(args) = value and obj(args) op= value, respecitvely. The same reasoning that took Walter and others to put in opIndex(Op)Assign apply to opCall(op)Assign.
Making opCall return a reference is not sufficient; an assignment to it might be subject to preconditions and thus not be valid in all cases.
Making opCall return a specially typed object that decays into the result value when read and checks preconditions on assignment needs a reference to the original object and is error prone. Also, it’s too much work for something that should be trivial.
This does not suggest to support l .. u or $ (for length) for opCall((Op)Assign).
Comment #1 by razvan.nitu1305 — 2022-09-23T09:24:24Z
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.
Comment #2 by qs.il.paperinik — 2022-10-10T10:53:16Z
(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.
Comment #3 by robert.schadek — 2024-12-13T19:24:34Z