Date: Thu, 6 Feb 2020 11:30:38 -0500
On 2/6/2020 9:56 AM, Henry Miller via Std-Proposals wrote:
>
>
> 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.
Daniel Gutson's N1466 proposal was made about 17 years ago. I guess in
C++ land that is not nearly long enough to wait for "named parameters".
You also seemed to ignore the Boost named parameter library I mentioned.
That has existed for 15 years now, and has not caused the C++ standards
committee to pursue "named parameters" or accept the library as a C++
standard library. But of course we should wait another 15 or 17 years
because anything could happen in that period of time.
I am actually all for named parameters, but given the current state of
C++, and the fact that named parameters has not happened for many, many
years, I do not see how making positional arguments with default
parameters easier to use is a bad thing. Even if an alternative named
parameters were to someday happen for C++, positional parameters would
not be going away.
>
> 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 comfort
> able 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.
Well of course one could design a software library so that instead of
one or two functions, templates, or whatever, with a number of default
parameters we could have a dozen functions, templates, or whatever, all
doing more or less the same thing. But I think the trend is for the
first: less functionality to invoke but greater flexibility.
>
>
> 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.
Daniel Gutson's N1466 proposal was made about 17 years ago. I guess in
C++ land that is not nearly long enough to wait for "named parameters".
You also seemed to ignore the Boost named parameter library I mentioned.
That has existed for 15 years now, and has not caused the C++ standards
committee to pursue "named parameters" or accept the library as a C++
standard library. But of course we should wait another 15 or 17 years
because anything could happen in that period of time.
I am actually all for named parameters, but given the current state of
C++, and the fact that named parameters has not happened for many, many
years, I do not see how making positional arguments with default
parameters easier to use is a bad thing. Even if an alternative named
parameters were to someday happen for C++, positional parameters would
not be going away.
>
> 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 comfort
> able 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.
Well of course one could design a software library so that instead of
one or two functions, templates, or whatever, with a number of default
parameters we could have a dozen functions, templates, or whatever, all
doing more or less the same thing. But I think the trend is for the
first: less functionality to invoke but greater flexibility.
Received on 2020-02-06 10:33:23