Ellipsis conversion operator...

Overview : Allows a conversion to be defined for passing classes to
variable argument lists.

Rational:

Currently proxy classes in C++ have a few cases where the existance is
exposed and the programmer needs to be aware that a proxy is in use.
This proposal only focuses on solving one of these issues: passing
proxy classes through a variable argument list.

Problem example: (assume correct includes etc...)
  int main(int argc, char** argv)
  {
    std::vector<bool> my_vector(5,false);
    std::vector<bool> const my_vector2(5,false);
    printf("Value of bit 3 is: %d\n", my_vector[3]); // problem
    printf("Value of bit 3 is: %d\n", my_vector2[3]); // works
    printf("Value of bit 3 is: %d\n", bool(my_vector[3])); // works
  }

Depending on the compilers I've tried you will either get an warning
message the reference proxy can not be passed through '...' or will get
the address of the proxy instead of the value.

Usage sample:
  class integer_proxy
  {
  public:
    explicit integer_proxy( int* src ) : value( src ) {}
    int operator...() const { return *value; }
  private:
    int* value;
  };

  int my_int = 5;
  integer_proxy func_returning_proxy()
  {
    return integer_proxy( &my_int );
  }

  int main( int argc, char** argv )
  {
    // This will print Value is: 5
    printf( "Value is: %d", func_returning_proxy() );
  }

Impact:

As referenced in 5.2.2   7, passing non-POD classes is currently
implementation-defined. Further the proposal only changes the meaning
of passing arguments of class type where operator... is defined. Also
the proposal does not suggest adding operator... to any class defined
in the standard library at this time. Thus it should not change the
meaning of any existing code.

Proposal Wording: (Based on n2914)

5.2.2   7
  Change "Passing a potentially-evaluated argument of class type"
  To:
    Passing an argument x of class type for which an operator... (13.7)
    has been declared is the same a passing x.operator...() [Note],
    otherwise passing a potentially-evaluated argument of class type

[Note: Standard conversions and integral promotions are applied to
the result of x.operator...() as if it has been the argument.]

13.5   1
  Add ... (ellipsis) to /operator/

 operator: one of
  new delete new[] delete[]
  + - * / %    & |
  ! = < > += -= *= /= %=
    = &= |= << >> >>= <<= == !=
  <= >= && || ++ -- , ->* ->
  ( ) [ ] ...

13.7 Ellipsis operator (New section)
  1. If declared in a class type, operator... shall be a non-static
member function
     taking no parameters. It implements a conversion applied to
arguments matched
     with the ellipsis parameter specification. (5.2.2   7)

A.11:
  Add ... (ellipsis) to /operator/, same wording as in 13.5   1


Alternate proposal:

Allow ... to an optional be part of the name of a conversion function.
  conversion-function-id:
     operator conversion-type-id ...opt

  i.e.:
    operator bool...() const;
  Would declare a conversion operator that would also be used for passing to
  variable aruments.

Problems I see with the alternate is that it requires more special casing, only
one conversion operator could have the ... bit, or should that be two
if there is
a constant and non-constant version. Also need to deal with operator
bool...() const
in declaration and operator bool() const in body. Finally it forces the
definition
of a conversion operator even if it is only intended for use when
passing to variable
arguments.




--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Daphne Pfister wrote:

> Ellipsis conversion operator...
>
> Overview : Allows a conversion to be defined for passing classes to
> variable argument lists.
>

I agree with the intent of the proposal, but I would propose an
alternative proposal to make it clear that operator...() is actually a
conversion function that provides a user-defined conversion.

Proposed wording (based on n2914):

Add to 5.2.2 [expr.call]/7 after "standard conversions":
   and the user-defined ellipsis conversion (12.3.3)

Add to 5.2.2 [expr.call]/7 after "are performed on the argument
expression.":
   These conversions will be applied recursively to the result as long as
one of them is applicable.

New section:
12.3.3 [class.conv.ellipsis] Ellipsis conversion
1  An overloaded operator... specifies a conversion from the type of the
class to the type specified by the operator... (REF). This conversion is
called an /ellipsis conversion/ and will only be applied when an
expression of the class type is used as an argument in a function call
for which there is no matching parameter (5.2.2). [Example:

   class X {
     //...
   public:
     int operator...();

   void f(X a)
   {
     printf( "%d", a ); // operator... used
   }

--end example]

Add to 13.5 [over.oper]/1 and A.11 [gram.over]:
   Add ... (ellipsis) to the production of /operator/
yielding:
   operator: one of
   new delete new[] delete[]
   + - * / % ? & | ?
   ! = < > += -= *= /= %=
   ?= &= |= << >> >>= <<= == !=
   <= >= && || ++ -- , ->* ->
   ( ) [ ] ...

New section:
13.5.8 [over.ellipsis] Ellipsis operator
1 operator... shall be a non-static member function taking no
parameters. It implements the ellipsis conversion (12.3.3).


The difference with the original proposal is that the use of operator...
is spelled out as a (user defined) conversion and that the ellipsis
conversion can be applied multiple times in a similar way as operator->.
The new wording also ensures that, if operator... returns an l-value,
array or function type, the appropriate conversions must be applied to
that result.

Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://c-faq.com/
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]