This is an informal suggestion. I've tried to state its usefulness as
best as I could.

[Abstract]
 One problem I find in C++ is the uncertainty of copy count in
non-assignment and non-scoping binary operators, such as +, -, *, /,
etc, and I know this is not just my own displeasure. My proposition is
that there should be an implicit definitions for the
operation/assignment operators (don't know the technical term), since
in all practicality, there shouldn't be a major difference between +
and +=. Adding to this, I think there should be another implicit
relationship, that "operator++" is the same as
"operator+=((int/size_t)1)", likewise that "operator--" is
"operator-=((int/size_t)1)", or "operator+="((int)-1)".
 Also, another reason for this is that rewriting similar code gets to
be a large pain. Whether or not I am alone in this opinion, I still
think this should be considered.
 This method shall allow definite implicitness, rather than uncertain
implicitness by optimizations that are compiler-specific.

NOTE: Assume "T" is any allowable type


[Aspects]
 As stated before, there shall be an implicit definition of the +=
operator, where + represents all the other related operators, including
itself: (-,*,/,%,&,|,^,<<,>>, ...)
  Example:
class A {
 A& operator+=(const T &x) { ... }
};
A a; T b;
"a+b" == "(A temp(a), temp+=b)", where temp is the temporary value used
to compute the operation
 //"A A::operator+(const T&)" is implicit
 //"==" is used in an abstract sense, meaning that the two expressions
are the same (one is expanded)
"a++" == "a+=1"
"a--" == "a-=1" In these two cases, I'm not sure how to handle
preceding unary increment/decrement operators, but I don't think this
concept is too difficult to grasp.
 Of course, the user shall be able to define explicit operators for
this (backwards compatibility), because disabling that would be
counter-productive, and too constraining.
 Also, const arguments/return values should be handled consistently. I
would state these, but I can't think of any extreme situations.


[Problems and Solutions]
 > There's the problem that a user might not state "A&" as the return
type for "operator+=(const T&)". If this happens, the compiler should
throw a warning, stating that the implicit option is no longer
available, since undefined behavior might ensue. Having "const A&"
shouldn't cause any such warnings.
 > The implicit declarations should be declared in the scope of the
accompanying operator. For some reason, if someone wants to declare
"operator+=" private (I have no idea why), the paired "operator+" would
be in the same scope, private.
 > One problem might be in associativity, whether the compiler should
implicitly define "A operator+(const T&,const A&)" if "a+b"=="b+a",
"a*b"=="b*a", etc.
 > Differences between class and global binary operator overloads ("A
A::operator+(const T&)" and "A operator+(const A&,const T&)") should be
established. The implicit declaration is only done in absence of a
class and global operator overload.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

deadimp@gmail.com wrote:
> Adding to this, I think there should be another implicit
> relationship, that "operator++" is the same as
> "operator+=((int/size_t)1)", likewise that "operator--" is
> "operator-=((int/size_t)1)", or "operator+="((int)-1)".

    It's not entirely clear what's wanted here, or what problem
this is supposed to solve.  But there are objects for which
"++" is meaningful, but "+=" is not.  Iterators for
non random access collection classes, for example.

    Besides, if you're doing extensive pointer arithmetic,
you're probably doing something wrong.  The major compilers
have all understood subscript optimization for a decade or
more now.

   John Nagle
   Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

> It's not entirely clear what's wanted here, or what problem
> this is supposed to solve.
It's not a major problem, nor does this solve all problems with
uncertain copy constructors.

> But there are objects for which
> "++" is meaningful, but "+=" is not.  Iterators for
> non random access collection classes, for example.
This aspect wouldn't be forced, but optional: "Of course, the user
shall be able to define explicit operators for
this [...] because disabling that would be counter-productive, and too
constraining."
A user could overload the implicit operators.

>     Besides, if you're doing extensive pointer arithmetic,
> you're probably doing something wrong.  The major compilers
> have all understood subscript optimization for a decade or
> more now.
Sorry for my ignorance, but what is subscript optimization?
Also, where am I doing pointer arithmetic? Or is this implied in a
situation using this concept?

Adding to the end of the first paragraph on the Abstract:
 These implicit operators would only exist if "operator+=(int)" and/or
"operator-=(int)" are defined.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

deadimp@gmail.com wrote:
> > It's not entirely clear what's wanted here, or what problem
> > this is supposed to solve.
> It's not a major problem, nor does this solve all problems with
> uncertain copy constructors.
>
> > But there are objects for which
> > "++" is meaningful, but "+=" is not.  Iterators for
> > non random access collection classes, for example.
> This aspect wouldn't be forced, but optional: "Of course, the user
> shall be able to define explicit operators for
> this [...] because disabling that would be counter-productive, and too
> constraining."
> A user could overload the implicit operators.

If += is meaningless, it shouldn't exist, at all; allowing the user to
provide a overload for it doesn't solve that problem. I'm not familiar
with the details of the "concepts" proposal, so I'm not sure how your
proposal would work with it. I could imagine that a concept requiring
the presence of an overload for operator+=() would, under your
proposal, automatically match any type defining an operator+(), and
that really shouldn't happen unless += is actually meaningful.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]