Date: Thu, 06 Feb 2020 08:56:40 -0600
On Wed, Feb 5, 2020, at 2:05 PM, Edward Diener via Std-Proposals wrote:
> On 2/5/2020 6:45 AM, Henry Miller via Std-Proposals wrote:
> >
> > There is a persistent request for named parameters that comes up every few months in some form here. none have gone anywhere, but if any do in some future revision, it should cover this as a trivial extension. I don't think we want two different syntaxes for the same thing and it seems to me that naming the non default parameters makes more sense than saying some paramater is some default value.
> >
> > That is I think before you go too far you should consider how alternatives would look in real code.
>
> I do not agree with your argument that because the future may hold some
> other theoretical solution to this problem, the simple use of 'default'
> for default arguments should not be considered now.
Remember the Vasa! http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0977r0.pdf
I strongly disagree, some future theoretical solution is reason to hold up this proposal - at least a little. There are some good arguments for named parameters, and some good arguments against them. However they are an alternative to your that have the advantage of solving other problems as well (with of course the downside of making some bad code easier to write than good code). As such when considering your proposal we must consider how it will interact with the possible future name parameter syntax since failing to consider that today may make the future even better things (if it is better) impossible.
Do we want to have the following two syntaxs: foo(default, SomeVariable) and foo(namedSecondParam=SomeVariable)? Yes is a valid answer, but it needs to be justified as to why it is worth it. Compiler writers do not like how complex C++ is to parse, and teams do not like it when two opinionated people spent time arguing which syntax is better - arguments that tend to drag on.
That isn't to say your proposal is bad, just that we need to consider other ways to achieve the same ends and choose the best. Sometimes the best overall is not the best for your problem in isolation.
At the same time, I agree that we need to not get caught up in analysis paralysis. Named parameters isn't currently going anywhere, and may never. I think it is a valid question for the language evolution working group of should it get anywhere. The first step is to define the problems - named parameters solve 5 problems (that I have discovered so far, if you know of more let me know), one of the problems is a negative where it would be best if it wasn't possible to do that (I can't think of how to stop it). One of the problems is the default case you are trying to solve. The real question of interest to you is how important are the various concerns, in particular are we willing to accept the long term future to get the default fix you propose in sooner - or alternatively are we comfortable with the status quo for most things but we want a solution to just this one issue.
I've been working (very slowly) on name parameters for a while anyone interested in my little progress can check https://github.com/HenryMiller1/cPlusPlusNamedParamaters. I've been trying to be neutral to your proposal as best I can. It isn't a bad idea, it just needs to fit into the larger context.
> My own experience is that a highly flexible software library often
> entails the extensive use of default template and function arguments.
There is a group that will say long lists of parameters is bad, therefore we shouldn't make it easier to work with. I agree with the idea in theory, but the real world is messy and so I often end up with longer than wanted argument lists. Be prepared for this argument if you go farther.
> On 2/5/2020 6:45 AM, Henry Miller via Std-Proposals wrote:
> >
> > There is a persistent request for named parameters that comes up every few months in some form here. none have gone anywhere, but if any do in some future revision, it should cover this as a trivial extension. I don't think we want two different syntaxes for the same thing and it seems to me that naming the non default parameters makes more sense than saying some paramater is some default value.
> >
> > That is I think before you go too far you should consider how alternatives would look in real code.
>
> I do not agree with your argument that because the future may hold some
> other theoretical solution to this problem, the simple use of 'default'
> for default arguments should not be considered now.
Remember the Vasa! http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0977r0.pdf
I strongly disagree, some future theoretical solution is reason to hold up this proposal - at least a little. There are some good arguments for named parameters, and some good arguments against them. However they are an alternative to your that have the advantage of solving other problems as well (with of course the downside of making some bad code easier to write than good code). As such when considering your proposal we must consider how it will interact with the possible future name parameter syntax since failing to consider that today may make the future even better things (if it is better) impossible.
Do we want to have the following two syntaxs: foo(default, SomeVariable) and foo(namedSecondParam=SomeVariable)? Yes is a valid answer, but it needs to be justified as to why it is worth it. Compiler writers do not like how complex C++ is to parse, and teams do not like it when two opinionated people spent time arguing which syntax is better - arguments that tend to drag on.
That isn't to say your proposal is bad, just that we need to consider other ways to achieve the same ends and choose the best. Sometimes the best overall is not the best for your problem in isolation.
At the same time, I agree that we need to not get caught up in analysis paralysis. Named parameters isn't currently going anywhere, and may never. I think it is a valid question for the language evolution working group of should it get anywhere. The first step is to define the problems - named parameters solve 5 problems (that I have discovered so far, if you know of more let me know), one of the problems is a negative where it would be best if it wasn't possible to do that (I can't think of how to stop it). One of the problems is the default case you are trying to solve. The real question of interest to you is how important are the various concerns, in particular are we willing to accept the long term future to get the default fix you propose in sooner - or alternatively are we comfortable with the status quo for most things but we want a solution to just this one issue.
I've been working (very slowly) on name parameters for a while anyone interested in my little progress can check https://github.com/HenryMiller1/cPlusPlusNamedParamaters. I've been trying to be neutral to your proposal as best I can. It isn't a bad idea, it just needs to fit into the larger context.
> My own experience is that a highly flexible software library often
> entails the extensive use of default template and function arguments.
There is a group that will say long lists of parameters is bad, therefore we shouldn't make it easier to work with. I agree with the idea in theory, but the real world is messy and so I often end up with longer than wanted argument lists. Be prepared for this argument if you go farther.
Received on 2020-02-06 08:59:38