Re: Overridability of _private_ predefined "=" [was Re: list strawman]

[Christoph Grein <christoph.grein@eurocopter.com>]

Please, before going into further discussions about reemergence of predefined 
operations and thinking about changing the language, read the corresponding 
chapters in the AARM (the Annotated Ada Reference Manual), e.g. AARM 
4.5.2(24a-c).

With respect to "block compare", this is not possible for tagged types, floating 
point types if there are signed zeros, and who knows for which other cases.

Thus it is generally a bad idea to override predefined operators for non-tagged 
types. If this is really necessary, then utmost care has to be applied 
everywhere such a type is used (e.g. as components of an array).

Reemergence has been introduced in the first place to avoid incompatibilities 
with Ada83.

Christoph Grein

> Its even worse than just that.  Now a "block compare" of any composite
> type
> that has a nontagged private type as a componant is questional because
> that
> comparison will utilize the predefined "=" of the private type even
> though
> the creator of the private type may have seen it proper to overridden
> it.
> 
> There was a thread, gosh, I guess less than two years ago where I was
> trying to
> argue that this was a disaster wrt generics and that reemergence of "="
> seemed
> to be a special case wrt the whole reemergence issue.   I now feel that
> the
> situation is very bad in general as opposed to being bad only wrt
> generics.
> 
> Does anyone think that it would be good for there to be a change in the
> language such that for private types, if a primative "=" returning
> boolean exists then it
> should be the "=" used as part of block compares and that the predefined
> one
> should not reemerge in generics?  This would not have been incompatible
> with
> Ada83, right?
> 
> I hope that the above is not perceved as rehashing old arguments - I do
> not
> remember the issues having been discussed exactly as above.
> 
> Vincent Marciante