A proposal for named arguments for C++ • Hacker News Board

Re: A proposal for named arguments for C++

#21

Post by BinaryIdiot » Thu, Oct 16, 2014, 3:06 AM UTC

MereInterest wrote: post #12

aleaonard54 wrote: post #10

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.

This! I love the idea simply because of this use case.

Re: A proposal for named arguments for C++

#22

Post by rootbear » Thu, Oct 16, 2014, 3:12 AM UTC

etimberg wrote: post #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 synta…

I agree this probably looks better in theory than it does in practice. As far as long function declarations go, it sure would be nice to go back to declaring multiple arguments of the same type without repeating the type:

  int myfunc(float x, y, z, r, g, b, a);

instead of

  int myfunc(float x, float y, float z, float r, float g, float b, float a);

Yes, I know about structs, but often that's not applicable. And if the type name is some long thing, then you have to really look carefully to notice they are all the same type. It seems this style is now being seen as a feature, although I don't know of any language that required repeating the type for each parameter until C and C++ adopted this for the new style function prototype declarations. I was very sorry to see that D has also adopted this "feature". I believe go allows multiple declarations of the same type. I'd much rather see this fixed in C and C++ than have them clutter up things with named parameters.

Re: A proposal for named arguments for C++

#23

Post by kentonv » Thu, Oct 16, 2014, 3:13 AM UTC

jschwartzi wrote: post #18

nkozyra wrote: 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.

No, this proposal does not affect the linker at all. Argument names would be resolved to positional arguments during compilation.

Re: A proposal for named arguments for C++

#24

Post by mappu » Thu, Oct 16, 2014, 3:18 AM UTC

StefanKarpinski wrote: post #19

jamesaguilar wrote: post #15

Earlier quoted context omitted.

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.

You still need to know whether the C library expects stdcall, pascal, cdecl, several variants of fastcall, as well as a dozen less popular conventions - and that's just on x86.

Stdcall convention in C also often does some name mangling (leading underscore, trailing @ and the number of bytes on stack) but not always.

Also a C++ ABI would need to extend beyond simple calling conventions and also specify fixed behaviour of vtables, which i think compiler authors might balk at.

Re: A proposal for named arguments for C++

#25

Post by dbaupp » Thu, Oct 16, 2014, 3:18 AM UTC

StefanKarpinski wrote: post #19

jamesaguilar wrote: post #15

Earlier quoted context omitted.

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.

The C ABI is a property of the platform, not the language itself.

Re: A proposal for named arguments for C++

#26

Post by kibwen » Thu, Oct 16, 2014, 3:19 AM UTC

StefanKarpinski wrote: post #19

jamesaguilar wrote: post #15

Earlier quoted context omitted.

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.

But not a standardized one, I think. Merely a few widely-used calling conventions (e.g. stdcall, cdecl).

Or am I misusing terminology?

Re: A proposal for named arguments for C++

#27

Post by pb2au » Thu, Oct 16, 2014, 3:29 AM UTC

robmccoll wrote: post #2

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

Pretty cool hack, but not one I'd hope to run across in any real code. Between the nondescript function header and the inability to differentiate between an unset argument and a zero-set one, this macro would too quickly become a headache.

Re: A proposal for named arguments for C++

#28

Post by kentonv » Thu, Oct 16, 2014, 3:30 AM UTC

StefanKarpinski wrote: post #19

jamesaguilar wrote: post #15

Earlier quoted context omitted.

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.

Nonsense. C doesn't even define the width of an int, without which an ABI makes no sense. An ABI is a property of a specific target platform (architecture and possibly OS); every platform defines its own. Windows and Linux on x86_64 don't even use the same ABI (the width of "long" is different, for starters). But both platforms have C++ ABIs just as much as they have C ABIs.

The problem with C++ ABIs is that C++ APIs tend to include much more substantial details in their headers. If you want to call a template or inline function, then you need a C++ compiler. Fundamentally, though, this is not any different from C macros -- a macro-heavy C API is going to require a C compiler to use.

Re: A proposal for named arguments for C++

#29

Post by jschwartzi » Thu, Oct 16, 2014, 3:35 AM UTC

kentonv wrote: post #23

jschwartzi wrote: post #18

Earlier quoted context omitted.

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.

No, this proposal does not affect the linker at all. Argument names would be resolved to positional arguments during compilation.

Yes, actually. You're right:

> In this proposal, the association of parameter names with a function for the purpose of making calls with named arguments to that function happens locally in each translation unit, and new declarations within a translation unit can change a function's ability to be called with named arguments at call sites below the new declaration (by using different names than a previous declaration).

Re: A proposal for named arguments for C++

#30

Post by captaincrowbar » Thu, Oct 16, 2014, 3:37 AM UTC

kentonv wrote: post #16

robmccoll wrote: post #2

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

I did something similar (without macros, with a bit more type safety since the keywords have an associated type, and with a shortcut for boolean arguments):

https://github.com/CaptainCrowbar/kwargs