Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!att!ulysses!andante!alice!ark
From: ark@alice.UUCP (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: Arguments to Overloaded Operators
Message-ID: <9454@alice.UUCP>
Date: 9 Jun 89 13:49:24 GMT
References: <11032@orstcs.CS.ORST.EDU> <1100@cadillac.CAD.MCC.COM> <238@pink.ACA.MCC.COM>
Organization: AT&T Bell Laboratories, Liberty Corner NJ
Lines: 24

In article <238@pink.ACA.MCC.COM>, rfg@pink.ACA.MCC.COM (Ron Guilmette) writes:

> I have heard that Bjarne had *some* good reason for not allowing overloading
> based on return types, but I never actually found out what that reason was.

The reason is that overloading based on return types would
mean abandoning the notion that an expression has a type.

Right now in C and C++ it is possible to figure out how to evaluate
an expression by doing a depth-first traversal of its parse tree:
once you have evaluated all the descendants of a node and found
their types, you have all the information you need to evaluate the
node itself.

If it were possible for the evaluation of a node to depend on the
type of its ancestors, in general that would mean that you'd have
to understand an entire expression to be able to evaluate any
of it.  That would make evaluation much harder to understand,
both for the compiler and for human programmers.  I would not be
surprised to find expression evaluation to be NP-hard under
those circumstances.
-- 
				--Andrew Koenig
				  ark@europa.att.com