Live data from Hacker News

A proposal for named arguments for C++

open-std.org

11–20 of 62 posts

Re: A proposal for named arguments for C++

#11

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.

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++

#12

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.

On the contrary, I would say that it cleans things up amazingly. As the language currently is, if I want to change one of the default values, I need to specify every single value up to that point.

    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++

#13
I like this idea in theory. the rectangle the example is a good one that I've personally tripped over before.

That 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++

#14
Please 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 only by the same C++ compiler).

Re: A proposal for named arguments for C++

#15

Please 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++

#16

One of my favorite C preprocessor hacks - emulating named parameters in C. https://gist.github.com/robmccoll/5236408528c8c664c201

If only named member initializers were supported in C++.

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):

https://gist.github.com/kentonv/7553792

Re: A proposal for named arguments for C++

#17

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.

What about reading? I can't always figure out what foo(0, xyz, null) means at first glance.

I can never remember the precise names of parameters. ;-)

Re: A proposal for named arguments for C++

#18
post #7

What's the argument against, well, named arguments? Is it a matter of brevity versus verbosity?

Well, function specifications in the link table would have to become more verbose, and the linker would have additional decisions to make. You could also wind up deferring a lot of problems that could be caught by compile-time checking until link-time, which might also be run-time.

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++

#19

Please 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.

C absolutely has an ABI – you do not need a C compiler to call a C library.

Re: A proposal for named arguments for C++

#20
post #7

What's the argument against, well, named arguments? Is it a matter of brevity versus verbosity?

It is exposing more implementation details to the consumer of an API. A function with named parameters can’t rename its parameters without callers needing to update all their named arguments. Not necessarily a bad thing. And verbosity isn’t so much an issue—I don’t mind writing a bit more code now if it’ll save me from a bughunt later.

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.

Post reply on HN