forked from ehsan/namedargs
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathnamedargs.html
519 lines (511 loc) · 24.8 KB
/
namedargs.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
<!-- vim: set ts=2 sw=2 tw=80 fo=tc et -->
<!DOCTYPE html>
<html>
<head>
<title>A proposal for named arguments for C++</title>
<style>
code { white-space: pre; }
</style>
</head>
<body>
<h3>Named arguments</h3>
<table>
<tr>
<th>Document number:</th><td>N4172</td>
</tr>
<tr>
<th rowspan=2>Authors:</th><td>Ehsan Akhgari (Mozilla), <[email protected]></td>
</tr>
<tr>
<td>Botond Ballo (Mozilla), <[email protected]></td>
</tr>
<tr>
<th>Date:</th><td>2014-10-07</td>
</tr>
</table>
<h4>Abstract</h4>
<p>We propose a new mechanism for associating function arguments with
function parameters: by name, with the syntax <code>name : value</code>. We
believe using named arguments will increase the readability of function
calls, as well as making it easier to write them and reducing the likelihood
of mistakes. Parameter names are associated with a function for the purpose
of a call by looking at the declarations of the function visible from the
call site; use of named arguments is allowed if all declarations use
consistent names.</p>
<h4>Motivation</h4>
<p>Function arguments are currently associated with function parameters by
position. This has implications for writing and reading function calls.</p>
<p>When writing a function call, one needs to be careful to write the
arguments in the same order as the parameters in the function declaration;
depending on the types of the parameters, the compiler can catch some
mistakes, but other times they lead to runtime bugs that are hard to
diagnose and prevent.</p>
<p>When reading a function call, the only information
about the purpose of the argument that is present at the call site is its
value and order relative to other arguments; for more information, the
reader needs to refer to the corresponding parameter's name in the function
declaration.</p>
<p>Function declarations are typically "far away" from function calls in
code, meaning elsewhere in the file or, more often, in a different file.
Therefore, we believe that a mechanism for associating function arguments
with function parameters that reduces the need to refer to the function
declaration when writing and reading function calls, would make both jobs
easier.</p>
<p>This is particularly the case for large software projects, where there
can be thousands of functions in play at once, and reliance on conventions
(such as "top, right, left, bottom") doesn't scale; and particularly the
case for C++, where gotchas such as implicit conversions mean that extra
care is required for things like argument order.</p>
<p>Another example of where this proposal is useful is with boolean arguments.
Some large software projects discourage the usage of the <code>bool</code>
type as an argument and require authors to use enums or consts to convey
what the boolean arguments mean at the call site. With this proposal, however,
boolean arguments can be used without the loss of readability at the call site.</p>
<p>We specifically propose that function arguments can be associated with
function parameters by using the parameter's name at the call site.</p>
<h5>Example</h5>
<p>Below is an example of the kind of code that can be written with what
is being proposed here.</p>
<code>
void draw_rect(int left, int top, int width, int height, bool fill_rect = false);
int main()
{
// Both of the function calls below pass the same set of arguments to draw_rect.
draw_rect(top: 10, left: 100, width: 640, height: 480);
draw_rect(100, 10, height: 480, fill_rect: false, width: 640);
}
</code>
<h4>Proposal</h4>
<h5>Syntax</h5>
The syntax of <em>expression-list</em> is extended to accept elements of
the form <em>identifier: expression</em>. Such elements are only allowed
as arguments to a function call. Arguments written this way are referred
to as <strong>named arguments</strong>. Non-named arguments are referred
to as <strong>positional arguments</strong>.
<h5>Basic semantics</h5>
Positional arguments
cannot appear after a named argument. If a function has
an ellipsis parameter or is a variadic template function, all of its
arguments at call sites must be positional. If a function declaration
includes parameters with default arguments, named arguments may give values
to some but
not all of the optional parameters. Here is an example:</p>
<code>
void foo(int a, char b, std::string c);
void bar(int a, char b='x', float c=0.1);
void baz(int a, ...);
template <class ...T> void qux(T... a);
void test() {
foo(1, 'c', "s"); // valid
foo(1, b: 'c', c: "s"); // valid
foo(a: 1, 'c', "s"); // invalid -- named argument followed by positional
foo(1, c: "s", b: 'c'); // valid
foo(1, 'c', c: "s"); // valid
bar(1, c: 0.2); // valid
bar(1, b: 'c'); // valid
bar(1, c: 0.2, b: 'c'); // valid
bar(a: 1); // valid
bar(a: 1, 'c'); // invalid -- named argument followed by positional
baz(a: 1); // invalid -- ellipsis parameter
baz(1, foo: 1); // invalid -- ellipsis parameter
qux(a: 1); // invalid -- variadic template function
}
</code>
<p>If the same function is declared more than once, it can only be called
using named arguments if the names or lack thereof for each parameter is
exactly the same in each declaration. Here is an example:</p>
<code>
void foo(int a, char b, std::string c);
void foo(int a, char b, std::string x);
void bar(int a, char b);
void bar(int x, char b);
void test() {
foo(1, 'c', "s"); // valid
foo(1, 'c', c: "s"); // invalid -- different names for an argument in multiple declarations
foo(1, 'c', x: "s"); // invalid -- different names for an argument in multiple declarations
bar(1, b: 'c'); // invalid -- different names for an argument in multiple declarations
}
</code>
<p>If the parameter list for a function drops some of the parameter names,
assuming that parameter N is the last to not have a name (nor a default argument),
all well-formed
calls to that function must provide at least N positional arguments. Here
is an example:</p>
<code>
void foo(int, char b, std::string c);
void bar(int, char b='c', float c=0.1);
void test() {
foo(1, c: "s", b: 'c'); // valid
bar(1, c: 0.2); // valid
bar(c: 0.2); // invalid - number of positional arguments (0) less than the index of the last unnamed parameter (1)
}
</code>
<p>As an exception, if a declaration does not provide names for any
arguments, it is ignored.</p>
<code>
void foo(int a, char b, std::string c);
void foo(int, char, std::string);
void test() {
foo(a: 1, b: 'c', c: "s"); // valid
}
</code>
<p>Functions definitions do not affect calling functions with named
arguments in any way. Example:</p>
<code>
void foo(int a, char b, std::string c);
void test() {
foo(c: "s", a: 1, b: 'c'); // valid
}
void foo(int x, char y, std::string z) {}
</code>
<p>This is true even if the definition is located prior to the call site:</p>
<code>
void foo(int a, char b, std::string c);
void foo(int x, char y, std::string z) {}
void test() {
foo(c: "s", a: 1, b: 'c'); // still valid
foo(x: 1, y: 'c', z: "s"); // still invalid
}
</code>
<p>However, if a function definition is the first declaration of a function,
the names of the parameters in the definition are considered. Example:</p>
<code>
void foo(int a, char b, std::string c) {}
void test() {
foo(c: "s", a: 1, b: 'c'); // valid
}
</code>
<p>If a following declaration then defines different names for the parameters,
using named arguments to call that function would be an error. Example:</p>
<code>
void foo(int a, char b, std::string c) {}
void foo(int x, char y, std::string z);
void test() {
foo(c: "s", a: 1, b: 'c'); // invalid -- different names for an argument in multiple declarations
}
</code>
<p>All of the above applies to function declarations/definitions in a single
translation unit. The same function may be declared in different translation
units with different parameter names, and each translation unit can have call
sites using the argument names that match the declaration in that translation
unit.</p>
<h5>Overload resolution</h5>
<p>Overload resolution needs to be modified slightly in order to handle
named arguments correctly. We do not propose to modify the rules for
determining the set of candidate functions and argument lists that are the
inputs to the overload resolution process <code>[over.match.funcs]</code>,
nor the rules for selecting the best viable function
<code>[over.match.best]</code>. We only propose to modify the rules for
determining which candidates are viable to begin with
<code>[over.match.viable]</code>, and our modifications only apply to calls
that involve named arguments.</p>
<p>Specifically, for calls that involve named arguments, we define rules
for matching arguments to parameters, and consider candidates where not all
arguments and parameters are matched according to these rules, to be not
viable.</p>
<p>Let's consider a function call with M positional arguments and N named
arguments. A given candidate function is viable if:</p>
<ul>
<li>The candidate has at least M + N parameters.</li>
<li>Disregarding the first M parameters of the candidate, every named
argument in the call can be matched to a parameter of the candidate by
name.</li>
<li>All parameters of the candidate which remain unmatched after the
above step have a default value.</li>
</ul>
<p>For a candidate function which is viable according to the above rules,
we adjust the argument list as follows: the N named arguments are reordered
to match the order of the parameters they have been matched with; if, for
some i < M + N, the i'th parameter of the function has no matching
argument - in which case, according to the above rules, it must have a
default argument - we match it with a synthetic argument using the value of
said default argument.</p>
<p>After this adjustment, the rest of the overload resolution process
proceeds as before.</p>
<p>Note that for function templates, the above matching and adjustment
process happens before template argument deduction (which requires
matched argument/parameter pairs).</p>
<h4>Interactions with other language features</h4>
<h5>Constructor calls with <code>{ ... }</code> syntax</h5>
<p>As part of C++11 "uniform initialization", constructors can be called
with a <code>{ }</code> syntax in addition to a <code>( )</code> syntax:</p>
<code>
struct S {
S(int a, std::string b);
...
};
S s(1, "foo");
S s{0, "bar"};
</code>
<p>We propose allowing the use of named arguments with both syntaxes:</p>
<code>
S s(a: 1, b: "foo"); // valid
S s{a: 0, b: "bar"}; // also valid
</code>
<h5>Aggregate initialization</h5>
<p>However, we do not propose allowing the use of named arguments with
aggregate initialization:</p>
<code>
struct S {
int a;
std::string b;
};
S s{1, "foo"}; // valid C++11
S s{a: 1, b: "foo"}; // not valid
</code>
<p>The rationale is that the names <code>a</code> and <code>b</code> here
are names of data members, whereas our proposal is about associating
arguments with parameter names.</p>
<p>We realize that this choice implies that the presence or absence of a
constructor in an aggregate class becomes more noticeable to users than
it was before. However, we believe that allowing the use of data member
names in the same syntax as named arguments has its own problems. For
example, adding a constructor to an aggregate class where the constructor
parameter names are different from the data member names could change the
meaning of the program. We believe disallowing this is the lesser of two
evils.</p>
<h5>Calls through function pointers</h5>
<p>Consider the following code:</p>
<code>
void func(int a, int b);
using funcptr_t = void (*)(int x, int y);
funcptr_t f = &func;
f(2, 3);
</code>
<p>Is it reasonable to allow a call to <code>f</code> to use named
arguments? If so, what names would be allowed?</p>
<p>Clearly, the names <code>a</code> and <code>b</code> are out of the
question, as they are the names of the function that the function pointer
points to, and what function a function pointer points to is a runtime
property of the program which the compiler cannot reason about.</p>
<p>However, perhaps it's reasonable to use the names <code>x</code> and
<code>y</code>, that is, the names of the parameters used in the declaration
of the function pointer, or (in case of a declaration using a typedef, as
here) in the declaration of the function pointer type?</p>
<p>We propose <strong>not</strong> allowing <code>x</code> and
<code>y</code> either, because it would require compilers to track parameter
names in typedef declarations and associate different declarations of a
typedef with each other to verify that the names are consistent. This
would cover new ground by giving typedef names a use they don't
currently have.</p>
<p>In summary, we propose disallowing named arguments for calls through
function pointers altogether.</p>
<h5>Perfect forwarding</h5>
<p>We've had a request to interoperate with perfect forwarding in such a way
that the following works:</p>
<code>
struct Rect {
Rect(int width, int height);
...
};
auto p = make_shared<Rect>(width: 100, height: 200);
</code>
<p>While we agree that having this work would be desirable, unfortunately we
are not aware of a way to make this work without making parameter names
part of a function's type, something we definitely do not propose (see
Design Choices below).</p>
<h4>Backwards Compatibility</h4>
<p>The changes in this proposal are fully backwards-compatible. All existing
programs will be valid with named arguments added to the language. Only
call sites which use named arguments are affected by this proposal.</p>
<h4>Design Choices</h4>
<h5>Syntax</h5>
<p>The <code>name : value</code> syntax was chosen because there is precedent
in other languages for using it to associate a key and a value (e.g. Python
dictionaries, and because it does not create any ambiguity.
<code>name=value</code> was considered, but rejected because "=" is an operator
and thus there would be an ambiguity. A ":" only current appears at the
beginning of a <em>ctor-initializer</em>, after an
<em>access-specifier</em>, or in a <em>labeled-statement</em>, all contexts
which are disjoint from <em>expression-list</em>, so there is no
ambiguity.</p>
<h5>Not making parameter names part of a function's type</h5>
<p>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).</p>
<p>A possible alternative would have been to encode parameter names in a
function's type, and thus have them be coupled more closely to the function
as an entity, possibly including across translation units.</p>
<p>We chose not to pursue this alternative because we felt it would be a
far more complex and invasive change to the language, with relatively
little gain. It would also likely be non-backwards-compatible both in terms
of source code backwards compatibility and ABI compatibility considering
mangling of names having to take the argument names into account.</p>
<h5>Automatically allowing existing functions to be called via named
arguments</h5>
<p>This proposal allows calling existing functions with named
arguments, without the author of the function having to "opt-in" to this in
any way.</p>
<p>We chose this because we believe this feature has sufficient value that
programmers should be able to start using it right away, without having to
wait for libraries and APIs to opt-in to named arguments. We also believe
that the potential for use in a way the author doesn't intend is low.</p>
<h4>Potential objections, and our responses</h4>
<h5>Objection #1: This feature caters to having functions with many
parameters - a programming style that should be discouraged.</h5>
<p>We agree that having functions with many parameters should be
discouraged. However, the reality is that many legacy APIs that
programmers have to work with and will have to work with for a long time,
have functions with many arguments, and making it easier to deal with such
functions would solve a real problem and be materially useful.</p>
<p>More importantly, however, this feature has a lot of value for functions
with few arguments, too. Even for functions with few arguments, when reading
a call site one has relatively little information about the roles of the
arguments. Having names of arguments present would make call sites more
readable, regardless of the number of arguments.</p>
<h5>Objection #2: This proposal competes with C99 designated initializers,
which are <a
href="http://htmlpreview.github.io/?https://raw.github.com/CTMacUser/multiarray-
iso-proposal/master/designation-proposal.html">being proposed for C++</a></h5>
<p>This proposal and designated initializers have in common that they both
allow the use of names to allow specifying a list of entities in an order
that's not necessarily the order of their declaration.</p>
<p>For C99 designated initializers, the entities being named are data
members of a structure (and this is reflected in the
<code>.name = value</code> syntax). In our proposal, the entities being
named are always parameters of a function (note that while we support
constructor calls via the <code>{ ... }</code>, we do not support
aggregate initialization (see "Interactions with other language features"
above)).</p>
<p>The two proposals therefore have no overlap, and we believe they are
complementary.</p>
<h5>Objection #3: Named arguments make parameter names part of a function's
interface, so that changing the parameter names can change call sites</h5>
<p>We were initially concerned about this as well. To get an idea about the
magnitude of this problem, we surveyed some large open-source libraries to
see how often parameter names change in the declarations of the public API
functions (i.e., the names that users would use when making calls to these
functions).</p>
<p>For each library, we chose a recent release and a release from several
years ago, examined the diff between the two versions, and recorded the
number of parameter name changes. Only name changes that preserved the types
of the parameters were considered, as a change to the type of a parameter
typically breaks a function's interface already. The table below summarizes
our findings. For more details, please see <a href="#ref1">[1]</a>.</p>
<table border="1" style="text-align: center">
<thead style="font-weight: bold">
<tr>
<td rowspan="2">Library</td>
<td colspan="2">Version Range</td>
<td rowspan="2">Number of Parameter<br>Name Changes</td>
</tr>
<tr>
<td>Start</td>
<td>End</td>
</tr>
</thead>
<tbody>
<tr>
<td><a
href="http://eigen.tuxfamily.org/index.php?title=Main_Page">Eigen</a></td>
<td>2.0.0 (2009)</td>
<td>3.0.0 (2011)</td>
<td>4</td>
</tr>
<tr>
<td><a href="http://wxwidgets.org/">wxWidgets</a></td>
<td>2.5.0.1 (2003)</td>
<td>3.0.0 (2013)</td>
<td>12</td>
</tr>
<tr>
<td><a
href="http://www.boost.org/doc/libs/release/libs/asio/">Boost.Asio</a></td>
<td>1.50.0 (2012)</td>
<td>1.55.0 (2013)</td>
<td>1</td>
</tr>
<tr>
<td><a
href="http://www.boost.org/doc/libs/release/libs/date_time/">Boost.DateTime</a>
</td>
<td>1.50.0 (2012)</td>
<td>1.55.0 (2013)</td>
<td>1</td>
</tr>
<tr>
<td><a
href="http://www.boost.org/doc/libs/release/libs/filesystem/">Boost.Filesystem
</a></td>
<td>1.45.0 (2010)</td>
<td>1.55.0 (2013)</td>
<td>0</td>
</tr>
<tr>
<td><a
href="http://www.boost.org/doc/libs/release/libs/gil/">Boost.GIL</a></td>
<td>1.45.0 (2010)</td>
<td>1.55.0 (2013)</td>
<td>0</td>
</tr>
<tr>
<td><a
href="http://www.boost.org/doc/libs/release/libs/math/">Boost.Math</a></td>
<td>1.45.0 (2010)</td>
<td>1.55.0 (2013)</td>
<td>22</td>
</tr>
<tr>
<td><a
href="http://www.boost.org/doc/libs/release/libs/regex/">Boost.Regex</a></td>
<td>1.45.0 (2010)</td>
<td>1.55.0 (2013)</td>
<td>0</td>
</tr>
<tr>
<td><a
href="http://www.boost.org/doc/libs/release/libs/thread/">Boost.Thread</a></td>
<td>1.45.0 (2010)</td>
<td>1.55.0 (2013)</td>
<td>4</td>
</tr>
</tbody>
</table>
<p>Given the low number of parameter name changes relative to the sizes of
these libraries over periods of several years, we believe that code breakage
due to parameter name changes would not be a significant problem in
practice.</p>
<h4>Implementation Status</h4>
<p>This proposal is not implemented yet. Most of the effort would be in
changes to the overload resolution phase of compilers. One of the authors of
this proposal has looked at the overload resolution implementation of clang,
and we believe the changes will be relatively straightforward to implement.
We have tried to ensure that the proposal makes as few changes to the
language as possible to avoid unnecessary implementation complexity.</p>
<h4>Standard Wording</h4>
<p>There is no standard wording for this proposal yet. At this stage, we
are mostly interested in getting general feedback.</p>
<h4>Possible extensions and spin-off ideas</h4>
<h5>Non-trailing default arguments</h5>
<p>With named arguments, it might become sensible to allow default arguments
in non-trailing positions. For example,</p>
<code>void f(int a = 10, int b);</code>
<p>could be called like so:</p>
<code>f(b: 5);</code>
<p>We have no objections to this, but would prefer leaving it to a follow-up
proposal to avoid scope creep.</p>
<h5>Named template arguments</h5>
<p>The arguments in favour or allowing named arguments for function calls
also apply to template arguments. We can imagine a similar proposal that
allows specifying template parametes via named arguments. For example:</p>
<code>
template <typename Key, typename Value>
struct map { ... };
map<Key: int, Value: string> m;
</code>
<p>We think it makes sense to pursue this as a separate proposal,
independent of this one.</p>
<h4>Acknowledgements</h4>
<p>We are grateful for the feedback received from numerous members of the
Mozilla community as well the C++ standards community.</p>
<h4>References</h4>
<ol>
<li><a name="ref1">A <a href="">study</a> performed on the
changes to argument names of the functions in the public interface of some
large open source projects.</a></li>
</ol>
</body>
</html>