On 9/04/2015 09:31, Jakob Riedle wrote:

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 arg = default ){ return; }

This would make things shorter, in the way 'auto' does it for types.

This may be a bikeshed, but why not use auto()? This would retain "auto" as "infer the appropriate type here" and "()" as "invoke with no parameters", together implying a constructor call. And it avoids overloading yet another keyword. It would have to de-reference intelligently when determining the constructor to call, though. Although ultimately if you're mostly concerned about typing long names, then typedef is your friend.

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 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 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 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()', 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

On Wed, Apr 8, 2015 at 5:31 PM, Jakob Riedle wrote:

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.

This posting is completely off-topic for Boost as it seems unrelated to Boost or Boost libraries. See www.boost.org/community/policy.html Please move this discussion to another mailing list, such as groups.google.com/a/isocpp.org/forum/#!forum/std-proposals Thanks, --Beman