On Tue, 14 Jul 2009 12:42:56 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Don wrote:
- Operator overloading. "completely redone" (?)
I think they should be redone. There are several issues:
1. Currently there's no provision for "expr1[expr2] @= expr3", where @
is some binary operator. The opIndexAssign is more like the token
presence that makes the absence felt even better. Scaling to
opIndexAddAssign etc. seems to be overkill.
2. Operators @= are dubious for classes because a class can't define "a
@= b" to mean the same as "a = a @ b". (I recall you were the first to
note that.) I'd venture to think that many arithmetic operators don't
make much sense for classes to start with.
3. There are types for which ++ or -- make sense but addition does not
(e.g. STL-style iterators).
4. opXxx_r and opXxx can easily be ambiguous, as you noted in a recent
thread. (I think that could be fixed with other means though.)
5. Defining operators asks for code duplication. Usually people want to
define all arithmetic operators to forward to some member. That is
unnecessarily verbose (see e.g. the implementation of std.variant which
makes heroic efforts to counter that).
Any other issues? (I feel I forgot a couple.) Maybe we can fix all of
these by patching the existing system.
I slicing and indexing need to be unified, as its common with
multi-dimensional data to slice one dimension and index another. Consider
slicing the first row of a matrix:
auto row0 = m[0,0..$];
(Also a multi-dimensional opDollar ->i.e. opDollar(size_t D){}, is needed)
