Re: proposal for new assignment operators

[Hyman Rosen <hyrosen@mail.com>]

Richard Riehle wrote:
 > For limited types, assignment is never possible.  Therefore,
> overloading assignment is not possible.

That "therefore" doesn't actually follow. In C++, to make assignment
impossible, you declare a private assignment operator. Surely it would
be no problem to say that assignment may not be overloaded for limited
types.

> It is rare that one even needs to override the assignment operator
> on a non-limited type.   There is a distinction here that will not
> be immediately obvious to the C++ programmer.

It's not that frequent to need to do it in C++ either, as long as you
avoid low-level types such as pointers that are better handled by
encapsulation in proper holder classes. Of course, in C++ you can define
assignment between different types, and then you do find yourself writing
assignment operators for describing that operation. For example, I might
have a simple
     template <typename T> struct ObjectHolder
     {
         T theObject;

         template <typename O>
         ObjectHolder &operator=(const ObjectHolder<O> &other)
         { theObject = other.theObject; return *this; }
      };
so that I can assign one kind of ObjectHolder to another. (This assignment
will be legal only when the underlying types are assignment compatible, and
will otherwise result in a compiler error message, so we are not decreasing
type safety here.)

> For a lot of very good reasons, the designers eschewed the C++ approach
> in favor of the Adjust approach. These reasons are discussed in some of
 > the literature that covers the rationale for the language design.

I looked at the section on Controlled types (7.4) in the Rationale and
didn't see any discussion about this, except for a remark about returning
limited types from functions. This leads me to believe that the "lot of
very good reasons" have to do with technical aspects of preserving
existing parts of Ada rather than abstract notions of how assignment
should be done properly. Not that there's anything wrong with that.