Boost logo

Boost :

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() {

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

If you overload

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

the call


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

There was a proposal "Let {expr} Be Explicit"

and its associated counter-proposal

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at