In article <3cgo4t$qi3@giga.bga.com>, Jamshid Afshar <jamshid@ses.com> wrote:

>>> The compiler said the draft working paper outlawed default parameter
>>> values for operators because such values couldn't really be used using
>>> operator syntax.
>
>I haven't read the latest WP about this, but this restriction has
>always existed in the ARM: 8.2.6 "An overloaded operator cannot have
>default arguments".  No explanation is provided, though, so I don't
>know if the operator() restriction is on purpose (eg, consistency) or
>an oversight.

In the general case, although in section ARM: 8.2.6 no reason is given, in
ARM: 13.4 p 330, the following statement is done:

 "The intent is to make C++ extensible, but not mutable. This
  protects the C++ programmer from the most obvious abuses of
  operator overloading, such as redefining + on integers to
  mean subtraction."

In a similar vein, allowing default arguments for operators in general would
make it possible to for example write

 Int Int::operator+(Int other = 1);

 Int a;
 a +;

would default arguments be allowed. Now, this calls for a judgement wether
this is tolerable. However, I agree with the fact that disallowing default
parameters in operator() is maybe a bit too restrictive.
--
Grtz, RFP ;-)

   |o|  Ruurd Pels, Kamgras 187, 8935 EJ  Leeuwarden, The Netherlands  |o|
   |o|            EU.net!sun4nl!wtrlnd!maxine!autpels!ruurd            |o|

In article <JASON.94Dec6131926@phydeaux.cygnus.com>,
Jason Merrill <jason@cygnus.com> wrote:
>>>>>> Scott Meyers <smeyers@netcom.com> writes:
>
>> The compiler said the draft working paper outlawed default parameter
>> values for operators because such values couldn't really be used using
>> operator syntax.

I haven't read the latest WP about this, but this restriction has
always existed in the ARM: 8.2.6 "An overloaded operator cannot have
default arguments".  No explanation is provided, though, so I don't
know if the operator() restriction is on purpose (eg, consistency) or
an oversight.

>> For most operators this is indeed the case, but it is
>> clearly not the case for operator().  My questions are twofold.  First,
>> is this restriction still in the current draft, and if so, what are the
>> chances the restriction will be lifted for operator() before the draft
>> is officially put out for public comment?
>
>I agree that this is pretty ridiculous.  g++ allows default parameters for
>operator(), operator++ and operator--, the latter two so that one
>implementation can be provided for both prefix and postfix variants).

Jamshid Afshar
jamshid@ses.com

A compiler I recently encountered rejected a declaration of the
function call operator where the parameters had default values:

  class Widget {
  public:
    int operator()(int = 0, int = 0);   // rejected
  };

The compiler said the draft working paper outlawed default parameter
values for operators because such values couldn't really be used using
operator syntax.  For most operators this is indeed the case, but it is
clearly not the case for operator().  My questions are twofold.  First,
is this restriction still in the current draft, and if so, what are the
chances the restriction will be lifted for operator() before the draft
is officially put out for public comment?

Thanks,

Scott

>>>>> Scott Meyers <smeyers@netcom.com> writes:

> The compiler said the draft working paper outlawed default parameter
> values for operators because such values couldn't really be used using
> operator syntax.  For most operators this is indeed the case, but it is
> clearly not the case for operator().  My questions are twofold.  First,
> is this restriction still in the current draft, and if so, what are the
> chances the restriction will be lifted for operator() before the draft
> is officially put out for public comment?

I agree that this is pretty ridiculous.  g++ allows default parameters for
operator(), operator++ and operator--, the latter two so that one
implementation can be provided for both prefix and postfix variants).

Jason