I hate this idea. It just clutters the UI too much and adds noise especially if it's a UI you're familiar with. The C/C++ language is noisy enough without all this. Modern IDEs alleviate the need to be reminded inline what the values are for. On top of the fact, just about every IDE invented in the last 10 years offers code completion making this useless IMHO.
A proposal for named arguments for C++
11–20 of 62 posts
Re: A proposal for named arguments for C++
#12I hate this idea. It just clutters the UI too much and adds noise especially if it's a UI you're familiar with. The C/C++ language is noisy enough without all this. Modern IDEs alleviate the need to be reminded inline what the values are for. On top of the fact, just about every IDE invented in the last 10 years offers code completion making this useless IMHO.
func(5,0,0,NULL,0,true,true,false,NULL,true);
func(verbose: true);
With named parameters, I can just specify the differences between my function call and the default values.Re: A proposal for named arguments for C++
#13That being said, this could hurt readability in some cases as single lines of code are going to get larger, especially with length parameter names. Another issue I forsee is a code style where parameters are prefixed with p_. Having to type that prefix each time would be annoying, but finding a readable syntax that allows a separately specified name will also be confusing.
Re: A proposal for named arguments for C++
#14Re: A proposal for named arguments for C++
#15Please stop adding features to C++ and standardize an ABI already. The lack of an ABI is why it's impossible to call C++ libraries without an entire C++ compiler – and it generally requires generating mountains of wrapper code a la SWIG – which is then called with the C ABI. The lack of an ABI is why dynamic libraries use C for writing extensions instead of C++: C++ can literally only be called by C++ (and in fact on…
Re: A proposal for named arguments for C++
#16One of my favorite C preprocessor hacks - emulating named parameters in C. https://gist.github.com/robmccoll/5236408528c8c664c201
Here's a similar hack that works in C++11, though it unfortunately requires declaring a global variable for each name (which I make less-bad by prefixing them with $, which is non-standard but supported by all major compilers):
Re: A proposal for named arguments for C++
#17I hate this idea. It just clutters the UI too much and adds noise especially if it's a UI you're familiar with. The C/C++ language is noisy enough without all this. Modern IDEs alleviate the need to be reminded inline what the values are for. On top of the fact, just about every IDE invented in the last 10 years offers code completion making this useless IMHO.
What about reading? I can't always figure out what foo(0, xyz, null) means at first glance.
Re: A proposal for named arguments for C++
#18What's the argument against, well, named arguments? Is it a matter of brevity versus verbosity?
The problem that they're trying to solve is that people often use 5 arguments when a single struct would do.
Re: A proposal for named arguments for C++
#19Please stop adding features to C++ and standardize an ABI already. The lack of an ABI is why it's impossible to call C++ libraries without an entire C++ compiler – and it generally requires generating mountains of wrapper code a la SWIG – which is then called with the C ABI. The lack of an ABI is why dynamic libraries use C for writing extensions instead of C++: C++ can literally only be called by C++ (and in fact on…
It's not really the responsibility of the standard committee, right? C also has no standard ABI.
Re: A proposal for named arguments for C++
#20What's the argument against, well, named arguments? Is it a matter of brevity versus verbosity?
However, I do find named parameters suspect, not just because I don’t care for names generally, but also because they’re just papering over the problem of a function with many parameters, some of which have the same type.
Faced with that problem, I usually reach for more descriptive types: enums instead of booleans, numbers that know about their units and axes and coordinate spaces, that sort of thing. Ideally, all arguments have different types and there is only one permutation of their order that the compiler will accept. It sounds onerous, but most of your functions probably satisfy this constraint already.