Re: [boost] [language] determine sence of language proposal concerning the 'default'-keyword

Subject: Re: [boost] [language] determine sence of language proposal concerning the 'default'-keyword
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-04-09 02:25:30

Le 08/04/15 23:31, Jakob Riedle a écrit :
> Hello boost community,
>
> since this seems to me kind of a proving ground for new C++ library/language features I'd ask this question here.
> Would you recon' writing a language proposal about:
>
> using the 'default'-keyword as some standard way of calling the default ctor of variables.
>
> I could imagine the following use-case:
>
> void foo( some::very_long_name<some_very_long_template_param> arg = default ){
>       return;
> }
>
> This would make things shorter, in the way 'auto' does it for types.
> You could also do it for passing parameters:
>
> foo( default );
>
>
IIUC, there are two features here. The 1st one to default a parameter 
with its EXPLICIT default constructor and the 2nd an anonymous EXPLICIT 
default constructor factory. Both are independent features even if we 
can think it is the same in a first glance.
Why? because the default is found in a different context.

Note that {} means already IMPLICIT default constructor.

struct E {
   explicit E() {}
};
struct I {
   I() {}
};

void f(I p = {});
void f(E p = {}); // compile rrror

tes.cpp:15:16: erreur: converting to ‘E’ from initializer list would use 
explicit constructor ‘E::E()’
  void f(E p = {});

void f2(I p);
void f3(E p);

void g() {
   f2({});
}

void h() {
   f3({}); // compile error
}

If you overload

void f(I1 p);
void f(I2 p)

the call

f({});

is ambiguous.

>
> This could interact very well with boost::optional, make it more intuitive and easier to use:
>
> optional<int> bar( optional<some_long_type_name> arg = default ){
>       return default;
> }
> bar( default );
>
I see here a 3rd feature.

     return default;

Note that the context is different. Here default is used as a return 
expression.

There was a proposal "Let {expr} Be Explicit"
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4074.pdf

and its associated counter-proposal 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4131.html

So your feature could be named "Let {} Be Explicit Default Constructor"

In the specific case of optional, you can just use nullopt

optional<int> bar( optional<some_long_type_name> arg = nullopt ){
      return nullopt;
}

bar( nullopt );

If what you want is something more generic, like the nullXXX, you could 
have a configurable function factory taking a function template that 
returns nullXXX

bar( null_<optional>() );

This of course implies that the result of null_<T> must be convertible 
to T<X> for all X, as it is the case for optional, unique_ptr, shared_ptr.

This, of course, doesn't responds to your default constructor factory.

> This way, you don't have to write 'optional<some_long_type_name>()', both at the parameter and at the function call.
> What do you think of such a language proposal?
>
The 1st use case would be less controversial than the 2nd and the 3rd 
one. The 3rd one is a specific case of the 2nd one and it has already 
have quite opposition. I don't think however the language needs these 
kind of features. Anyway you can always post something into the std 
future proposals ML, where you could have more and possible different 
feedback.

Best,
Vicente