In article <JASON.94Apr15181458@deneb.cygnus.com>,
Jason Merrill <jason@cygnus.com> wrote:
>>>>>> Kevlin Henney <kevlin@wslint.demon.co.uk> writes:
>
>>  class Avoidable
>>  {
>>  public:
>>   operator void() { cout << "Avoidable" << endl; }
>>  };
>
>The current Working Paper disallows this code:
>
>"If conversion-type-id is void or cv-qualified void, the program is
>ill-formed."
>
>So explicitly casting to void cannot differ semantically from simply
>ignoring the value.

This discussion brings up another point that's been bugging me for a while.
The ARM discusses in section 13 (.0) how functions differing only in return
type cannot be overloaded.  It gives the example:

X operator+(const X&, const Y&);
Y operator+(const X&, const Y&);

void f(X a, Y b)
{
    X r1 = a+b;
    Y r2 = a+b;
}

Then talks about how it is difficult for a computer or human to determine
which call is really meant.  How does this case differ from:

class B;
class C;

class A {
  public:
    A();
    operator B();
    operator C();
};

class B {
  public:
    B();
};

class C {
  public:
    C();
};

void f(A &a)
{
    B b = a;
    C c = a;
}

Conversion operators are *always* overloaded only on return type.  Why can't
we just have similar rules for function overloading?

- Brad
------------------------------------------------------------------------
+ Brad Daniels                  | "Let others praise ancient times;    +
+ Biles and Associates          |  I am glad I was born in these."     +
+ These are my views, not B&A's |           - Ovid (43 B.C. - 17 A.D.) +
------------------------------------------------------------------------