Date: Tue, 12 Nov 2019 23:07:38 -0600
I understand your issues but I think issue number one could issue a
compiler warning if you have no specified default value because I can see
the with unit testing using default could be used to limit the input
parameters as you care to test versus do not care about the extra input
parameters. Your second issue I was thinking to extend it to pointers and
reference as there the case but the case nullprt is a
relevant default value. As for reference what does it means to have a
default value as the default value would first be needed to be constructed
before the function called and would be invisible and what is the lifetime
of a default reference object?
On Tue, Nov 12, 2019 at 4:33 PM Edward Diener via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> On 11/12/2019 2:09 PM, Vishal Oza via Std-Proposals wrote:
> > I would like to propose a new language feature into the language.
> >
> > The feature is to allow writing default in function values to have
> > default value feed into the function/method as a part of the language.
> >
> > int foo(int bar = 3, int baz = 7, int* foobar = nullptr, int* foobaz =
> > nullptr) { ... }
> > ...
> >
> > int foobazval = 78;
> >
> > auto fooval = foo(13, default, default, &foobazval); // = foo(13,
> > 7, nullptr, &foobazval)
> >
> > if the function have no default value calling default would be the same
> > as calling the default constructor. Errors would include assigning a
> > default value to a reference type and assigning default to a type with
> > no default constructor.
>
> As I said previously I like your proposal except for:
>
> 1) Specifying 'default' for a parameter which has no default should be
> illegal and a compiler error.
> 2) There is absolutely no reason why a reference type parameter with a
> default value, which is perfectly legal but rarely specified, should be
> treated any differently than any other default value.
>
> My two objections is to keep this proposal as simple as possible without
> creating totally unnecessary one-off cases.
>
> I would also add that default parameters in C++ also occur in class and
> function templates and there is no reason why the same use of the
> 'default' keyword could not be used in those situations also as part of
> your proposal.
>
> >
> > As a side note I have been told that as a extension allowing a to
> > specify function names could also solve the same problem but I do not
> > want to push for this hard as I think is can break code where the
> > interface definition does not match the implementation. This second
> > approach would allow C++ developer to only assign to field the the need
> > in as order they want like in the example bellow.
> >
> > auto fooval = foo( bar : 13, foobaz : &foobazval);
>
> As I noted preciously Boost already has a named parameter library called
> Boost Parameter for those who want to use named parameters, but your
> basic proposal should be seen as an easy to use alternative to that with
> almost no overhead and a clear syntactical ease of use.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
compiler warning if you have no specified default value because I can see
the with unit testing using default could be used to limit the input
parameters as you care to test versus do not care about the extra input
parameters. Your second issue I was thinking to extend it to pointers and
reference as there the case but the case nullprt is a
relevant default value. As for reference what does it means to have a
default value as the default value would first be needed to be constructed
before the function called and would be invisible and what is the lifetime
of a default reference object?
On Tue, Nov 12, 2019 at 4:33 PM Edward Diener via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> On 11/12/2019 2:09 PM, Vishal Oza via Std-Proposals wrote:
> > I would like to propose a new language feature into the language.
> >
> > The feature is to allow writing default in function values to have
> > default value feed into the function/method as a part of the language.
> >
> > int foo(int bar = 3, int baz = 7, int* foobar = nullptr, int* foobaz =
> > nullptr) { ... }
> > ...
> >
> > int foobazval = 78;
> >
> > auto fooval = foo(13, default, default, &foobazval); // = foo(13,
> > 7, nullptr, &foobazval)
> >
> > if the function have no default value calling default would be the same
> > as calling the default constructor. Errors would include assigning a
> > default value to a reference type and assigning default to a type with
> > no default constructor.
>
> As I said previously I like your proposal except for:
>
> 1) Specifying 'default' for a parameter which has no default should be
> illegal and a compiler error.
> 2) There is absolutely no reason why a reference type parameter with a
> default value, which is perfectly legal but rarely specified, should be
> treated any differently than any other default value.
>
> My two objections is to keep this proposal as simple as possible without
> creating totally unnecessary one-off cases.
>
> I would also add that default parameters in C++ also occur in class and
> function templates and there is no reason why the same use of the
> 'default' keyword could not be used in those situations also as part of
> your proposal.
>
> >
> > As a side note I have been told that as a extension allowing a to
> > specify function names could also solve the same problem but I do not
> > want to push for this hard as I think is can break code where the
> > interface definition does not match the implementation. This second
> > approach would allow C++ developer to only assign to field the the need
> > in as order they want like in the example bellow.
> >
> > auto fooval = foo( bar : 13, foobaz : &foobazval);
>
> As I noted preciously Boost already has a named parameter library called
> Boost Parameter for those who want to use named parameters, but your
> basic proposal should be seen as an easy to use alternative to that with
> almost no overhead and a clear syntactical ease of use.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2019-11-12 23:10:16