Re: Redefinition of Equality (Long)

[dewar@schonberg.cs.nyu.edu (Robert Dewar)]

Bob said

"In article <52hgmoINN7tg@snoopy.cis.ohio-state.edu>,
david scott gibson <dgibson@snoopy.cis.ohio-state.edu> wrote:
>In order to compare the elements from two sets, a redefined equality
>function must remove elements from the sets first. ...

It seems highly undesirable for "=" to modify its parameters.  If you
want to implement "=" in terms of some destructive operations, then you
ought to make a copyof the parameters first.  Why is this a problem?

I certainly agree that functions should allow 'in out' parameters, but
not so you can write evil "=" operations.  But even if 'in out' were
allowed, you would still have your problem, because for *tagged* types
an overriding operation has to be subtype conformant with what it's
overriding.
"


I completely agree with Bob here. In fact it is this kind of suggestion
of serious misuse of the ability to have in out parameters for functions
that feeds the enthusiasim of the rabid anti-side-effects-in-functions
folks :-)

Actually as we have discussed this issue over and over again, more and more
such horrible proposed uses have appeared, and although I still wish that
this very annnoying restrictions would have been lifted at LEAST for
interfaced functions, where the ability is really important, I must say
that I have to agree more than I did that this capability invites misuse.

Bob's analysis of why this feature did NOT go in is quite right. In fact
the requirements document (of which i was one of the authors) casually
mentioned the relaxation of this restriction as a *possible* example
of what we meant by stating the priniciple that unenecessary and 
undesirable restrictions should be removed.

A majority of all comments received on the requirements document were
rants and raves about even the *suggestion* that this restriction should
be dropped :-)