• d-bugmail puremagic.com (29/29) Sep 21 2022 https://issues.dlang.org/show_bug.cgi?id=23353

d-bugmail puremagic.com writes:

https://issues.dlang.org/show_bug.cgi?id=23353

          Issue ID: 23353
           Summary: Add opCallAssign and opCallOpAssign
           Product: D
           Version: D2
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P1
         Component: dmd
          Assignee: nobody puremagic.com
          Reporter: qs.il.paperinik gmail.com

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).

--