Discussion:
[RFC] Uniform designated initializers and arguments for C++ (implementation available)
(too old to reply)
TONGARI J
2016-04-13 08:33:28 UTC
Permalink
Hi,

The draft can be viewed at:
http://jamboree.github.io/designator-draft.html

The prototype based on Clang can be found at:
https://github.com/jamboree/clang/tree/feature/designator


I'm not sure if it's proper to submit a new proposal before C++17 is
settled, anyway, I'd like to make this work public now.
Please let me know if anyone wants to be a champion if it's submitted.


Thanks
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e2d5660e-2cf7-4107-868d-7027bdce344f%40isocpp.org.
Giovanni Piero Deretta
2016-04-13 10:13:50 UTC
Permalink
Post by TONGARI J
Hi,
http://jamboree.github.io/designator-draft.html
https://github.com/jamboree/clang/tree/feature/designator
I'm not sure if it's proper to submit a new proposal before C++17 is
settled, anyway, I'd like to make this work public now.
Not much to say. Seems a pretty good proposal. I like the syntax for
opting-in on named function arguments.

-- gpd
Post by TONGARI J
Thanks
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5c5ebfb8-bfc1-4526-8b8a-752aa3f64a77%40isocpp.org.
Vadim Petrochenkov
2016-04-13 10:29:09 UTC
Permalink
As a some practical example, qemu is a large project written in C and it
uses designated initializers all over the place (they are irreplaceable for
large aggregates).
If you try to compile qemu code as C++, then designated initializers is
probably the largest reason preventing it from compiling.
I'm not talking that qemu is ever going to be converted to C++, but
designated initializers (even in their simplest form `{ .field = value }`)
can be helpful for migrating other C libraries into C++.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/07f79d12-b072-49c3-81f7-1a3b27809510%40isocpp.org.
Andrey Semashev
2016-04-13 10:54:28 UTC
Permalink
Post by TONGARI J
Hi,
http://jamboree.github.io/designator-draft.html
https://github.com/jamboree/clang/tree/feature/designator
I'm not sure if it's proper to submit a new proposal before C++17 is
settled, anyway, I'd like to make this work public now.
Please let me know if anyone wants to be a champion if it's submitted.
In a few places in the proposal document, you state that
copy-initialization is used with designated initializers. This is not so
with normal initializers or positional function arguments and depends on
whether the initialized member/argument is a reference. Is this
difference intentional? If yes, then what's the rationale for it (as it
doesn't look reasonable to me)?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/72f36085-ebd3-f485-4c27-cf9d73883e04%40gmail.com.
TONGARI J
2016-04-13 12:33:49 UTC
Permalink
Post by Andrey Semashev
Post by TONGARI J
Hi,
http://jamboree.github.io/designator-draft.html
https://github.com/jamboree/clang/tree/feature/designator
I'm not sure if it's proper to submit a new proposal before C++17 is
settled, anyway, I'd like to make this work public now.
Please let me know if anyone wants to be a champion if it's submitted.
In a few places in the proposal document, you state that
copy-initialization is used with designated initializers. This is not so
with normal initializers or positional function arguments and depends on
whether the initialized member/argument is a reference. Is this difference
intentional? If yes, then > what's the rationale for it (as it doesn't look
reasonable to me)?
In the "Design decisions" section?
It's not intentional, I'll try to improve the wording...
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANCwVhd02bieqqrz6i%2Be8E1HwKKQqOjjxRRsTm7xE66y9CvvdQ%40mail.gmail.com.
q***@gmail.com
2016-04-13 17:59:02 UTC
Permalink
2.3 can be solved by much smaller change in standard.
Do you consider allowing such syntax:

obj.f(default, b)
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b9692187-ba5d-42eb-b07c-e98e07d0878e%40isocpp.org.
TONGARI J
2016-04-14 01:56:20 UTC
Permalink
Post by q***@gmail.com
2.3 can be solved by much smaller change in standard.
obj.f(default, b)
Actually I did. This could be useful in its own, but it's outside the scope
of this proposal.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1c310d01-9084-4b8b-b77c-df752c0affa8%40isocpp.org.
Richard Smith
2016-04-13 19:31:17 UTC
Permalink
This looks more or less like how I'd always imagined designated
initializers would work in C++. Thanks for writing this! One question, you
say:

"3.2.1.1 Function redeclaration

If a function is declared with designatable parameters and/or default
arguments, it cannot be redeclared with designatable parameters and/or
default arguments, otherwise, the program is ill-formed."

This seems very strange to me. I would expect that:
a) every declaration of the same function must specify the same
designatable parameters, with the same names, and
b) perhaps overloading on designated parameter names should be permitted

One example of why (b) would be useful:

struct my_complex {
my_complex(double .rho, double .theta);
my_complex(double .real, double .imag);
};

Here, these constructors could *only* be called with designated parameter
names, because any non-designated call would be ambiguous.
Post by TONGARI J
Hi,
http://jamboree.github.io/designator-draft.html
https://github.com/jamboree/clang/tree/feature/designator
I'm not sure if it's proper to submit a new proposal before C++17 is
settled, anyway, I'd like to make this work public now.
Please let me know if anyone wants to be a champion if it's submitted.
Thanks
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e2d5660e-2cf7-4107-868d-7027bdce344f%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e2d5660e-2cf7-4107-868d-7027bdce344f%40isocpp.org?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqm6csXjnPy69xt6p0E365JYL92UPns5cHBebckP-7Sdaw%40mail.gmail.com.
Ville Voutilainen
2016-04-13 19:33:31 UTC
Permalink
This looks more or less like how I'd always imagined designated initializers
"3.2.1.1 Function redeclaration
If a function is declared with designatable parameters and/or default
arguments, it cannot be redeclared with designatable parameters and/or
default arguments, otherwise, the program is ill-formed."
a) every declaration of the same function must specify the same designatable
parameters, with the same names, and
b) perhaps overloading on designated parameter names should be permitted
struct my_complex {
my_complex(double .rho, double .theta);
my_complex(double .real, double .imag);
};
Here, these constructors could *only* be called with designated parameter
names, because any non-designated call would be ambiguous.
Just out of curiosity, how do you plan to mangle those names? The
reason why I ask is that
sure, yeah, such overloading could be handy, but it also introduces
additional complexity
to deal with.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZbCGMJZRvWSoVdWCzDuoJUORex6972UdPPt29Yx6s_Jg%40mail.gmail.com.
Richard Smith
2016-04-13 19:48:36 UTC
Permalink
On Wed, Apr 13, 2016 at 12:33 PM, Ville Voutilainen <
Post by Vadim Petrochenkov
Post by Richard Smith
This looks more or less like how I'd always imagined designated
initializers
Post by Richard Smith
"3.2.1.1 Function redeclaration
If a function is declared with designatable parameters and/or default
arguments, it cannot be redeclared with designatable parameters and/or
default arguments, otherwise, the program is ill-formed."
a) every declaration of the same function must specify the same
designatable
Post by Richard Smith
parameters, with the same names, and
b) perhaps overloading on designated parameter names should be permitted
struct my_complex {
my_complex(double .rho, double .theta);
my_complex(double .real, double .imag);
};
Here, these constructors could *only* be called with designated parameter
names, because any non-designated call would be ambiguous.
Just out of curiosity, how do you plan to mangle those names?
As a modifier immediately preceding or following the mangled type of the
parameter. (And for what it's worth, I think it'd also be useful for the
name to be part of the function type, with a standard conversion to remove
the parameter names, but I'm not necessarily convinced the added complexity
is worth it.)

The
Post by Vadim Petrochenkov
reason why I ask is that
sure, yeah, such overloading could be handy, but it also introduces
additional complexity
to deal with.
I agree, but I don't think this mangling aspect is a big deal. The original
proposal introduces more significant mangling complexities regardless of
whether we allow overloading -- in a function template signature,
decltype(f(.a=T())) and decltype(f(T())) must mangle differently if T is a
dependent type, for instance.

If we go ahead with this proposal but don't allow overloading, I expect
people to fake it:

struct my_complex {
private:
struct polar_tag {};
struct cartesian_tag {};
public:
my_complex(double .rho, double .theta, polar_tag = {});
my_complex(double .real, double .imag, cartesian_tag = {});
};
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqmOyWz6VsAvJ%2BxxS2RADnfYuWgZkE-uF26m1wTnP_QMSQ%40mail.gmail.com.
Ville Voutilainen
2016-04-13 20:10:37 UTC
Permalink
Post by Richard Smith
Post by Ville Voutilainen
The
reason why I ask is that
sure, yeah, such overloading could be handy, but it also introduces
additional complexity
to deal with.
I agree, but I don't think this mangling aspect is a big deal. The original
proposal introduces more significant mangling complexities regardless of
whether we allow overloading -- in a function template signature,
decltype(f(.a=T())) and decltype(f(T())) must mangle differently if T is a
dependent type, for instance.
Well, I don't think it's the biggest hurdle either. A much bigger
hurdle is having this proposal
survive five minutes after its presentation, because the previous ones
dropped dead in about that time.
Let me draw you a paraphrased caricature of what usually happens when
named arguments are proposed:

1) a "both sides must opt in" proposal comes in. The response is "this
doesn't help anyone in the near future, and makes
function declarations more complex, for questionable benefit. Either
use stronger and different types, or a parameter
type that has named setters, or <insert various work-around
suggestions here>..."

2) a "works automatically" proposal comes in. The response is "well,
that doesn't work with the standard library,
and authors of other libraries don't want to have the introduced
requirement to provide stable names without their opt-in,
so <insert the work-arounds again>..."

3) in either case, the complexity and its ratio to the apparent
benefit get strongly questioned.

Yeah, sure, this proposal doesn't look half bad. But I have no
illusions that it would somehow magically avoid all of the
opposing arguments that all previous proposals for named arguments have faced.
Post by Richard Smith
If we go ahead with this proposal but don't allow overloading, I expect
struct my_complex {
struct polar_tag {};
struct cartesian_tag {};
my_complex(double .rho, double .theta, polar_tag = {});
my_complex(double .real, double .imag, cartesian_tag = {});
};
For some values of "people", maybe. But introducing such new kind of
overloading will probably meet resistance,
and be fuel for questioning the cost/benefit ratio.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbocHoNgadLm1xMCkCyt_31A9sWYOowCeVNxv0Mbop1kw%40mail.gmail.com.
Matthew Woehlke
2016-04-13 20:49:57 UTC
Permalink
A much bigger hurdle is having this proposal survive five minutes
after its presentation, because the previous ones dropped dead in
about that time.
1) a "both sides must opt in" proposal comes in. The response is
"this doesn't help anyone in the near future, and makes function
declarations more complex, for questionable benefit.
Would it be the end of the world to make the following be synonymous?

int square(int .x);
int square([[named("x")]] int);
int square([[named("x")]] int not_x);

I realize that attributes with meaning aren't loved, but the advantage
this has is addressing the 'not useful *now*' complaint, by making it
possible to write code (without using macros) that can be compiled with
a C++11 compiler that still provides named arguments when used with a
newer compiler. It also addresses the standard library to some extent,
as it permits adding named arguments to the API while still allowing the
implementation to use whatever it wants for names.

Note that this would however preclude encoding the argument names into
the ABI.
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nembdl%24frg%241%40ger.gmane.org.
Ville Voutilainen
2016-04-13 21:18:59 UTC
Permalink
Post by Matthew Woehlke
A much bigger hurdle is having this proposal survive five minutes
after its presentation, because the previous ones dropped dead in
about that time.
1) a "both sides must opt in" proposal comes in. The response is
"this doesn't help anyone in the near future, and makes function
declarations more complex, for questionable benefit.
Would it be the end of the world to make the following be synonymous?
int square(int .x);
int square([[named("x")]] int);
int square([[named("x")]] int not_x);
I'm not quite sure what you're suggesting there. Make them synonymous, as in
allow all of those various syntaxes?
Post by Matthew Woehlke
I realize that attributes with meaning aren't loved, but the advantage
this has is addressing the 'not useful *now*' complaint, by making it
No, the "not useful now" complaint is that in order to use named arguments,
the call site obviously needs to say that it uses them, but in an
opt-in proposal
the declaration also has to say so. Therefore both a user and a (whatever, not
necessarily the standard) library author need to decide that they want
such a thing.
That is in contrast to the other kinds of proposals where the caller
can just name
(except when the arguments can't be named, like with standard library functions)
the arguments so that the names are picked up from some declaration. Whatever
syntax you come up with, the issues remain. You may disagree on whether that's
an issue, but the real complaint is that some audiences don't want
named arguments
because then there's potentially lots of churn (or at least requests
for such churn)
in many codebases to add support for them, for arguably questionable benefit.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYaBy%3DejRYaJcJTSw7VVM_X%2Bmb%3D8MRxyP3MvZZ5Czad2g%40mail.gmail.com.
Matthew Woehlke
2016-04-13 21:39:13 UTC
Permalink
Post by Ville Voutilainen
Post by Matthew Woehlke
A much bigger hurdle is having this proposal survive five minutes
after its presentation, because the previous ones dropped dead in
about that time.
1) a "both sides must opt in" proposal comes in. The response is
"this doesn't help anyone in the near future, and makes function
declarations more complex, for questionable benefit.
Would it be the end of the world to make the following be synonymous?
int square(int .x);
int square([[named("x")]] int);
int square([[named("x")]] int not_x);
I'm not quite sure what you're suggesting there. Make them synonymous, as in
allow all of those various syntaxes?
Yes. As in, all three lines would a) be allowed and b) have the same
meaning.
Post by Ville Voutilainen
Post by Matthew Woehlke
I realize that attributes with meaning aren't loved, but the advantage
this has is addressing the 'not useful *now*' complaint, by making it
No, the "not useful now" complaint is that in order to use named
arguments, the call site obviously needs to say that it uses them,
but in an opt-in proposal the declaration also has to say so.
Therefore both a user and a (whatever, not necessarily the standard)
library author need to decide that they want such a thing.
But this is a direct result of the parameter names not being implicitly
part of the API (i.e. your "authors of other libraries don't want to
have the introduced requirement to provide stable names without their
opt-in"). If both complaints are fatal to any possible proposal, then we
cannot make progress, because we *must* accept one or the other of those
limitations.

That may be the case. If so, however, it would be good to know (and
perhaps document?) so that we can shoot down any named argument
proposals immediately as being fundamentally intractable.

The idea behind the above was to provide a not-too-painful mechanism
that would let authors that aren't willing to commit to C++20 to write
libraries that can require only C++11 but still provide named argument
support without too much pain, so that libraries can be forward-looking
in order to mitigate that complaint.
Post by Ville Voutilainen
That is in contrast to the other kinds of proposals where the caller
can just name (except when the arguments can't be named, like with
standard library functions) the arguments so that the names are
picked up from some declaration.
Again, the suggestion is intended to mitigate this (especially the
standard library case), by having an API argument name that is separate
from the "actual" name as used by the implementation. (I would argue
that if you aren't willing to commit to a stable API argument name, you
aren't committing to a stable API, period.)
Post by Ville Voutilainen
You may disagree on whether that's an issue
I don't. I recognize that there are legitimate concerns from both sides,
and am trying to come up with a way to at least mitigate (note: *not*
"eliminate"; I suspect that's impossible) them so that progress can be
made. I made the above suggestion in the hopes that it might be useful
in that sense, though I suspect it isn't, much :-(.
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nemea1%24uq8%241%40ger.gmane.org.
Ville Voutilainen
2016-04-13 21:55:45 UTC
Permalink
Post by Matthew Woehlke
Post by Ville Voutilainen
Post by Matthew Woehlke
Would it be the end of the world to make the following be synonymous?
int square(int .x);
int square([[named("x")]] int);
int square([[named("x")]] int not_x);
I'm not quite sure what you're suggesting there. Make them synonymous, as in
allow all of those various syntaxes?
Yes. As in, all three lines would a) be allowed and b) have the same
meaning.
Well, I will not make end-of-the-world predictions, but such an idea
is guaranteed to generate
strong opposition. Partly because it complicates the idea, partly
because it's using attributes
for semantics.
Post by Matthew Woehlke
Post by Ville Voutilainen
No, the "not useful now" complaint is that in order to use named
arguments, the call site obviously needs to say that it uses them,
but in an opt-in proposal the declaration also has to say so.
Therefore both a user and a (whatever, not necessarily the standard)
library author need to decide that they want such a thing.
But this is a direct result of the parameter names not being implicitly
part of the API (i.e. your "authors of other libraries don't want to
have the introduced requirement to provide stable names without their
opt-in"). If both complaints are fatal to any possible proposal, then we
cannot make progress, because we *must* accept one or the other of those
limitations.
Well, perhaps that's one of the reasons why named arguments have
failed every time.
Post by Matthew Woehlke
That may be the case. If so, however, it would be good to know (and
perhaps document?) so that we can shoot down any named argument
proposals immediately as being fundamentally intractable.
Well - 'automatic' ones are highly questionable because they don't
work with the standard library,
unless everything in it changes, which is not backwards compatible,
which means we can probably
skip to an 'opt-in'. I'm not sure whether I know all the
counterarguments and opposition of it.
I have indeed toyed with the idea of writing a rumination paper on why
named arguments have failed,
as far as I know and have observed it (which doesn't cover all the old
proposals), but perhaps I was
kinda hoping I wouldn't need to. :)
Post by Matthew Woehlke
The idea behind the above was to provide a not-too-painful mechanism
that would let authors that aren't willing to commit to C++20 to write
libraries that can require only C++11 but still provide named argument
support without too much pain, so that libraries can be forward-looking
in order to mitigate that complaint.
Ah, so the expectation is that a C++11 implementation would just
ignore the attributes it doesn't grok,
and a C++20 implementation would give them semantic meaning. That is a
silent change in meaning
of code, and those tend to have a short life expectancy.
Post by Matthew Woehlke
Post by Ville Voutilainen
That is in contrast to the other kinds of proposals where the caller
can just name (except when the arguments can't be named, like with
standard library functions) the arguments so that the names are
picked up from some declaration.
Again, the suggestion is intended to mitigate this (especially the
standard library case), by having an API argument name that is separate
from the "actual" name as used by the implementation. (I would argue
that if you aren't willing to commit to a stable API argument name, you
aren't committing to a stable API, period.)
Well, today, and for multiple decades, an argument name has been an
implementation detail,
nothing more. Hence the argument that not providing a stable name
means not providing a
stable API cannot possibly be sound.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYvzGPWJyrPjQRrg-RQYVbDN%3DExc036D5fP14xuiutS2A%40mail.gmail.com.
Matthew Woehlke
2016-04-14 14:19:21 UTC
Permalink
Post by Ville Voutilainen
Well - 'automatic' ones are highly questionable because they don't
work with the standard library, unless everything in it changes,
which is not backwards compatible,
...Why? Parameter names today have no effect on the generated code. If
we take the route that they don't affect the ABI, then why can't they be
changed in order to conform to a new codification of what they should be?

(OTOH, of course, that's a massive change to codify all the parameter
names everywhere... it could be done piecemeal, though, with the
standard providing no guarantees except where the names are specified.)
Post by Ville Voutilainen
Post by Matthew Woehlke
Post by Matthew Woehlke
Would it be the end of the world to make the following be synonymous?
int square(int .x);
int square([[named("x")]] int);
int square([[named("x")]] int not_x);
The idea behind the above was to provide a not-too-painful mechanism
that would let authors that aren't willing to commit to C++20 to write
libraries that can require only C++11 but still provide named argument
support without too much pain, so that libraries can be forward-looking
in order to mitigate that complaint.
Ah, so the expectation is that a C++11 implementation would just
ignore the attributes it doesn't grok, and a C++20 implementation
would give them semantic meaning. That is a silent change in meaning
of code, and those tend to have a short life expectancy.
...no? There are no named parameter semantics in C++11/14/17. The only
change would be that a new feature is available in (e.g.) C++20. I don't
see how this would be any different from C11 designated initializers vs.
C89/C99. The only change is a pure *addition*; you can do something you
couldn't do before.

Mind, I'm assuming that parameter names do *not* affect the ABI, and
that if it affects the function pointer type, a function pointer type
with named parameters decays into the same signature less the parameter
names. If either of those is not the case, then yes, my idea would not
be reasonable :-).
Post by Ville Voutilainen
Post by Matthew Woehlke
(I would argue that if you aren't willing to commit to a stable API
argument name, you aren't committing to a stable API, period.)
Well, today, and for multiple decades, an argument name has been an
implementation detail, nothing more. Hence the argument that not
providing a stable name means not providing a stable API cannot
possibly be sound.
I didn't say "won't", I said "not willing". There is a subtle
difference. Yes, the name has no compiler-defined semantic at present.
What it *does* have is a user-defined semantic. The argument, in other
words, is to ask why you would need to *change* the parameter name, once
a reasonable one has been selected (and therefore made part of the API),
if the user semantic of the parameter has not changed. The obvious
reasons (change of semantic meaning of the parameter, massive change of
coding style) imply that your API *is actually different*, and
therefore, an API break is not only warranted, it may be a *feature*.

Especially with my idea that would allow separating API name from
implementation name, such a change becomes *by definition* an API
change. (Note also that I'm assuming an opt-in approach at least at the
political level; i.e. in case of an automatic approach, a library might
explicitly disclaim API compatibility across versions w.r.t. parameter
names.)

I'd be interested in examples why you would *need* to change a parameter
name (as exported in the API) when the semantic meaning of the parameter
is *not* changed.
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/neo8ta%242go%241%40ger.gmane.org.
Ville Voutilainen
2016-04-14 14:41:11 UTC
Permalink
Post by Matthew Woehlke
Post by Ville Voutilainen
Well - 'automatic' ones are highly questionable because they don't
work with the standard library, unless everything in it changes,
which is not backwards compatible,
...Why? Parameter names today have no effect on the generated code. If
we take the route that they don't affect the ABI, then why can't they be
changed in order to conform to a new codification of what they should be?
Because my standard library implementation needs to work with elder
front-ends, so
in order to add conditional support for named arguments, you need a
strong argument that named
arguments are useful and necessary. Every proposal author that has
proposed named
arguments has thus far failed to do that.
Post by Matthew Woehlke
Post by Ville Voutilainen
Post by Matthew Woehlke
Post by Matthew Woehlke
Would it be the end of the world to make the following be synonymous?
int square(int .x);
int square([[named("x")]] int);
int square([[named("x")]] int not_x);
The idea behind the above was to provide a not-too-painful mechanism
that would let authors that aren't willing to commit to C++20 to write
libraries that can require only C++11 but still provide named argument
support without too much pain, so that libraries can be forward-looking
in order to mitigate that complaint.
Ah, so the expectation is that a C++11 implementation would just
ignore the attributes it doesn't grok, and a C++20 implementation
would give them semantic meaning. That is a silent change in meaning
of code, and those tend to have a short life expectancy.
...no? There are no named parameter semantics in C++11/14/17. The only
change would be that a new feature is available in (e.g.) C++20. I don't
see how this would be any different from C11 designated initializers vs.
C89/C99. The only change is a pure *addition*; you can do something you
couldn't do before.
Yes, except that the meaning of the function declaration changes depending on
which front-end you use. I'm probably going to use a macro for such a
thing, at which
point the usefulness of supporting such an attribute there becomes
nil, because I can
just macro the dot-name of the argument while I'm at it.
Post by Matthew Woehlke
Post by Ville Voutilainen
Well, today, and for multiple decades, an argument name has been an
implementation detail, nothing more. Hence the argument that not
providing a stable name means not providing a stable API cannot
possibly be sound.
I didn't say "won't", I said "not willing". There is a subtle
difference. Yes, the name has no compiler-defined semantic at present.
What it *does* have is a user-defined semantic. The argument, in other
I fail to see what that user-defined "semantic" could possibly be.
Post by Matthew Woehlke
words, is to ask why you would need to *change* the parameter name, once
a reasonable one has been selected (and therefore made part of the API),
if the user semantic of the parameter has not changed. The obvious
reasons (change of semantic meaning of the parameter, massive change of
coding style) imply that your API *is actually different*, and
therefore, an API break is not only warranted, it may be a *feature*.
I fail to see how a change of coding style implies that the API is
different. Sure,
such an API break *may* be a feature, it may not.
Post by Matthew Woehlke
Especially with my idea that would allow separating API name from
implementation name, such a change becomes *by definition* an API
change. (Note also that I'm assuming an opt-in approach at least at the
political level; i.e. in case of an automatic approach, a library might
explicitly disclaim API compatibility across versions w.r.t. parameter
names.)
I'd be interested in examples why you would *need* to change a parameter
name (as exported in the API) when the semantic meaning of the parameter
is *not* changed.
I'm not sure whether I can find such examples. But other people report
they can easily
find examples where a declaration has a long elaborated name for a
parameter, and
the definition has a very terse name. The terse names may easily be changed over
time, and might e.g. become less terse. Even with your proposed
name-mapping, that
means changing multiple declarations, so named arguments do make such
name changes
much harder. So the question becomes "why bother"?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYjitT7t%2BFq7VnKmDmud8xUwoNs0SLaiBAY94_NyrynKw%40mail.gmail.com.
Matthew Woehlke
2016-04-14 15:20:13 UTC
Permalink
Post by Ville Voutilainen
Post by Matthew Woehlke
Post by Ville Voutilainen
Well - 'automatic' ones are highly questionable because they don't
work with the standard library, unless everything in it changes,
which is not backwards compatible,
...Why? Parameter names today have no effect on the generated code. If
we take the route that they don't affect the ABI, then why can't they be
changed in order to conform to a new codification of what they should be?
Because my standard library implementation needs to work with elder
front-ends,
...but we were talking about *automatic* named parameters. We already
established that the parameter names don't matter currently, so why is
changing them to match an updated standard an issue?

In any case, I'm not seeing an issue here that can't be fixed with
macros, or (at least for "elderly" being minimum C++11) my attribute idea.
Post by Ville Voutilainen
Post by Matthew Woehlke
Post by Ville Voutilainen
Post by Matthew Woehlke
Post by Matthew Woehlke
Would it be the end of the world to make the following be synonymous?
int square(int .x);
int square([[named("x")]] int);
int square([[named("x")]] int not_x);
The idea behind the above was to provide a not-too-painful mechanism
that would let authors that aren't willing to commit to C++20 to write
libraries that can require only C++11 but still provide named argument
support without too much pain, so that libraries can be forward-looking
in order to mitigate that complaint.
Ah, so the expectation is that a C++11 implementation would just
ignore the attributes it doesn't grok, and a C++20 implementation
would give them semantic meaning. That is a silent change in meaning
of code, and those tend to have a short life expectancy.
...no? There are no named parameter semantics in C++11/14/17. The only
change would be that a new feature is available in (e.g.) C++20. I don't
see how this would be any different from C11 designated initializers vs.
C89/C99. The only change is a pure *addition*; you can do something you
couldn't do before.
Yes, except that the meaning of the function declaration changes
...in what way? You keep asserting this, but I am not understanding what
change you think is occurring. I can only assume therefore that we
aren't talking about the same implementation.

Given:

int add(int [[named("a")] a, int [[named("b")]] b);

In both cases you have a function with the signature `int (int, int)`
(either because names aren't part of the type, or at least that decays
to that). In both cases, you can call the function like `add(2, 3);`.
All that has changed is that in one case you can *also* call it like
`add(.b = 3, .a = 2);`.

Again, this wasn't an issue for C11. Why would it be an issue for C++?
Post by Ville Voutilainen
I'm probably going to use a macro for such a thing, at which point
the usefulness of supporting such an attribute there becomes nil,
because I can just macro the dot-name of the argument while I'm at
it.
Maybe. The advantage of the attribute is that it does not require a
macro (for people that hate those, and for people that care about
namespacing it properly), and allows the API name and implementation
name to be different.

Is that worth it? Maybe not :-).
Post by Ville Voutilainen
Post by Matthew Woehlke
Post by Ville Voutilainen
Well, today, and for multiple decades, an argument name has been an
implementation detail, nothing more. Hence the argument that not
providing a stable name means not providing a stable API cannot
possibly be sound.
I didn't say "won't", I said "not willing". There is a subtle
difference. Yes, the name has no compiler-defined semantic at present.
What it *does* have is a user-defined semantic. The argument, in other
I fail to see what that user-defined "semantic" could possibly be.
The function/meaning of the parameter. For example, in `sin(double
.radians)`, the "user semantic" of `radians` is 'an angle in radians'.
If I want to rename that to `degrees`, it is a *feature* that this is an
API break, because the API did in fact change in a non-compatible
manner. This is different from "compiler semantic" because the compiler
(at least currently) has no way to diagnose if I pass degrees to a
function that expects radians, or vice versa.

Given a function where the parameter name is part of the API, I expect
that name to relate to the user-semantic of the parameter. A change in
the name¹ therefore implies a change in the user-semantic of the
parameter, which is an API break. Hopefully that makes sense now?

(¹ Tony V.E. already covered the one case I can think of where one might
reasonably want to rename a parameter where no semantic change occurs.
See also my reply there.)
Post by Ville Voutilainen
Post by Matthew Woehlke
I'd be interested in examples why you would *need* to change a parameter
name (as exported in the API) when the semantic meaning of the parameter
is *not* changed.
I'm not sure whether I can find such examples. But other people
report they can easily find examples where a declaration has a long
elaborated name for a parameter, and the definition has a very terse
name. The terse names may easily be changed over time, and might e.g.
become less terse.
Sounds like an advantage of my attribute idea.
Post by Ville Voutilainen
Even with your proposed name-mapping, that means changing multiple
declarations,
Not if we don't allow overloading on names?²

// header
int foo(int [[named("bar")]] maybe_bar);

// implementation
int foo(int not_bar) // note: API name not repeated
{ ... }

(² FWIW, I'll note that Python doesn't - at least not without jumping
through hoops - allow overloading *at all*, so this doesn't seem like an
unreasonable limitation. Especially if we ever get strong type aliases,
which would allow type overloading for most of the cases where you'd
otherwise want name overloading.)
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/neocfe%242o8%241%40ger.gmane.org.
Ville Voutilainen
2016-04-14 15:30:06 UTC
Permalink
Post by Matthew Woehlke
Post by Ville Voutilainen
Post by Matthew Woehlke
Post by Ville Voutilainen
Well - 'automatic' ones are highly questionable because they don't
work with the standard library, unless everything in it changes,
which is not backwards compatible,
...Why? Parameter names today have no effect on the generated code. If
we take the route that they don't affect the ABI, then why can't they be
changed in order to conform to a new codification of what they should be?
Because my standard library implementation needs to work with elder
front-ends,
...but we were talking about *automatic* named parameters. We already
established that the parameter names don't matter currently, so why is
changing them to match an updated standard an issue?
Because I expect that in that newer standard they won't be uglified,
whereas they
need to be when an older standard is used, so now I have to write conditional
code. I don't have time to do such nonsensical work unless the
motivation for it is strong.
Post by Matthew Woehlke
In any case, I'm not seeing an issue here that can't be fixed with
macros, or (at least for "elderly" being minimum C++11) my attribute idea.
Yay, so we fix a problem with macros, and now we have two problems. :)
Post by Matthew Woehlke
Post by Ville Voutilainen
Post by Matthew Woehlke
Post by Ville Voutilainen
Post by Matthew Woehlke
Post by Matthew Woehlke
Would it be the end of the world to make the following be synonymous?
int square(int .x);
int square([[named("x")]] int);
int square([[named("x")]] int not_x);
The idea behind the above was to provide a not-too-painful mechanism
that would let authors that aren't willing to commit to C++20 to write
libraries that can require only C++11 but still provide named argument
support without too much pain, so that libraries can be forward-looking
in order to mitigate that complaint.
Ah, so the expectation is that a C++11 implementation would just
ignore the attributes it doesn't grok, and a C++20 implementation
would give them semantic meaning. That is a silent change in meaning
of code, and those tend to have a short life expectancy.
...no? There are no named parameter semantics in C++11/14/17. The only
change would be that a new feature is available in (e.g.) C++20. I don't
see how this would be any different from C11 designated initializers vs.
C89/C99. The only change is a pure *addition*; you can do something you
couldn't do before.
Yes, except that the meaning of the function declaration changes
...in what way? You keep asserting this, but I am not understanding what
change you think is occurring. I can only assume therefore that we
aren't talking about the same implementation.
int add(int [[named("a")] a, int [[named("b")]] b);
In both cases you have a function with the signature `int (int, int)`
(either because names aren't part of the type, or at least that decays
to that). In both cases, you can call the function like `add(2, 3);`.
All that has changed is that in one case you can *also* call it like
`add(.b = 3, .a = 2);`.
Well, duh, I can now also call the function like that because the meaning
of the function declaration changed. Had it not changed, I wouldn't be able
to call it that way. The meaning now changes automatically, regardless
of whether
I change anything anywhere. I might not want that, which is why I would probably
macro-conditionalize the declaration anyway, and therefore the
attribute doesn't help
me at all.
Post by Matthew Woehlke
Post by Ville Voutilainen
Post by Matthew Woehlke
Post by Ville Voutilainen
Well, today, and for multiple decades, an argument name has been an
implementation detail, nothing more. Hence the argument that not
providing a stable name means not providing a stable API cannot
possibly be sound.
I didn't say "won't", I said "not willing". There is a subtle
difference. Yes, the name has no compiler-defined semantic at present.
What it *does* have is a user-defined semantic. The argument, in other
I fail to see what that user-defined "semantic" could possibly be.
The function/meaning of the parameter. For example, in `sin(double
.radians)`, the "user semantic" of `radians` is 'an angle in radians'.
If I want to rename that to `degrees`, it is a *feature* that this is an
API break, because the API did in fact change in a non-compatible
manner. This is different from "compiler semantic" because the compiler
(at least currently) has no way to diagnose if I pass degrees to a
function that expects radians, or vice versa.
In other words, you think you can make names have a "user semantic" if
named arguments are supported. That doesn't mean that all names have such
"user semantics", because currently none of them do, hence my confusion about
what these "user semantics" are. Today, they are a figment of imagination. With
named arguments, they might be a thing, although they might not be. I wouldn't
call that the strongest rationale for named arguments.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYniDB%3DtnGxERowN9qattWardzCYXhxn95sdCHfAOe4_A%40mail.gmail.com.
Matthew Woehlke
2016-04-14 15:57:39 UTC
Permalink
Post by Ville Voutilainen
Post by Matthew Woehlke
...but we were talking about *automatic* named parameters. We already
established that the parameter names don't matter currently, so why is
changing them to match an updated standard an issue?
Because I expect that in that newer standard they won't be uglified,
whereas they need to be when an older standard is used,
I don't get it. If parameter names don't matter in "old" C++, why must
the 'ugly' names be used? What am I missing?
Post by Ville Voutilainen
Post by Matthew Woehlke
[...] the meaning of the function declaration changes
...in what way? You keep asserting this, but I am not understanding what
change you think is occurring. I can only assume therefore that we
aren't talking about the same implementation.
int add(int [[named("a")] a, int [[named("b")]] b);
In both cases you have a function with the signature `int (int, int)`
(either because names aren't part of the type, or at least that decays
to that). In both cases, you can call the function like `add(2, 3);`.
All that has changed is that in one case you can *also* call it like
`add(.b = 3, .a = 2);`.
Well, duh, I can now also call the function like that because the meaning
of the function declaration changed. Had it not changed, I wouldn't be able
to call it that way.
Huh?

Let me try rephrasing this. Let's say we have a C struct:

struct foo { int bar };

In C89, the "meaning" of this struct is that I can construct it like
`{1}`. In C11, the "meaning" is that I can (additionally) construct it
like `{.bar=1}`. This was evidently not a problem for C11. What "change
of meaning" occurs in C++ that is different from this example and
therefore problematic?
Post by Ville Voutilainen
Post by Matthew Woehlke
The function/meaning of the parameter. For example, in `sin(double
.radians)`, the "user semantic" of `radians` is 'an angle in radians'.
If I want to rename that to `degrees`, it is a *feature* that this is an
API break, because the API did in fact change in a non-compatible
manner. This is different from "compiler semantic" because the compiler
(at least currently) has no way to diagnose if I pass degrees to a
function that expects radians, or vice versa.
In other words, you think you can make names have a "user semantic" if
named arguments are supported.
They would (when employed) become part of the public API in the same
manner as the function name, with similar issues arising if you want to
change the names. (In fact, I hadn't realized this before... the same
problems that would arise with renaming named parameters *already exist*
w.r.t. the name of the function itself. And yet, somehow we're managing.)
Post by Ville Voutilainen
That doesn't mean that all names have such
"user semantics", because currently none of them do, hence my confusion about
what these "user semantics" are. Today, they are a figment of imagination. With
named arguments, they might be a thing, although they might not be. I wouldn't
call that the strongest rationale for named arguments.
Ah... I think you perhaps misunderstand the intended scope. This
particular argument is not meant as an argument *for* named parameters,
only as an argument why the concern about "committing my API to a name"
is possibly overemphasized.
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/neoelk%249ko%241%40ger.gmane.org.
Ville Voutilainen
2016-04-14 16:03:04 UTC
Permalink
Post by Matthew Woehlke
Post by Ville Voutilainen
Post by Matthew Woehlke
...but we were talking about *automatic* named parameters. We already
established that the parameter names don't matter currently, so why is
changing them to match an updated standard an issue?
Because I expect that in that newer standard they won't be uglified,
whereas they need to be when an older standard is used,
I don't get it. If parameter names don't matter in "old" C++, why must
the 'ugly' names be used? What am I missing?
Macros must not leak in?
Post by Matthew Woehlke
Post by Ville Voutilainen
Post by Matthew Woehlke
[...] the meaning of the function declaration changes
...in what way? You keep asserting this, but I am not understanding what
change you think is occurring. I can only assume therefore that we
aren't talking about the same implementation.
int add(int [[named("a")] a, int [[named("b")]] b);
In both cases you have a function with the signature `int (int, int)`
(either because names aren't part of the type, or at least that decays
to that). In both cases, you can call the function like `add(2, 3);`.
All that has changed is that in one case you can *also* call it like
`add(.b = 3, .a = 2);`.
Well, duh, I can now also call the function like that because the meaning
of the function declaration changed. Had it not changed, I wouldn't be able
to call it that way.
Huh?
struct foo { int bar };
In C89, the "meaning" of this struct is that I can construct it like
`{1}`. In C11, the "meaning" is that I can (additionally) construct it
like `{.bar=1}`. This was evidently not a problem for C11. What "change
of meaning" occurs in C++ that is different from this example and
therefore problematic?
With an opt-in, there is no problem, since I can choose with a macro
whether I opt in or not.
I can do that without the attributes you propose. So, again, those
attributes don't seem to be useful.
I don't want to use such attributes because then the opt-in happens
half-automatically, although
I admit that's not a huge problem because nobody is forcing me to use
those attributes.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbO7BRVJtqaKkorPUQwkFAyyEy6OcE-svfyQVpwU7BODQ%40mail.gmail.com.
Matthew Woehlke
2016-04-14 16:46:43 UTC
Permalink
Post by Ville Voutilainen
Post by Matthew Woehlke
Post by Ville Voutilainen
Post by Matthew Woehlke
...but we were talking about *automatic* named parameters. We already
established that the parameter names don't matter currently, so why is
changing them to match an updated standard an issue?
Because I expect that in that newer standard they won't be uglified,
whereas they need to be when an older standard is used,
I don't get it. If parameter names don't matter in "old" C++, why must
the 'ugly' names be used? What am I missing?
Macros must not leak in?
Do you mean that, for example std::map::find cannot use `key` as the
parameter name in case the user has done `#define key` somewhere?

If yes, a) wouldn't that be a problem for a "modern" standard library
with codified parameter names also, and b) isn't this solved by my
attribute idea? (In particular, because the parameter name given in an
attribute is quoted, it should not be subject to PP 'tampering'. This is
not the case with `.name` as in the original proposal.)
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/neohhj%24r38%241%40ger.gmane.org.
Ville Voutilainen
2016-04-14 17:54:07 UTC
Permalink
Post by Matthew Woehlke
Post by Ville Voutilainen
Post by Matthew Woehlke
I don't get it. If parameter names don't matter in "old" C++, why must
the 'ugly' names be used? What am I missing?
Macros must not leak in?
Do you mean that, for example std::map::find cannot use `key` as the
parameter name in case the user has done `#define key` somewhere?
Yes.
Post by Matthew Woehlke
If yes, a) wouldn't that be a problem for a "modern" standard library
with codified parameter names also, and b) isn't this solved by my
Excellent question. :) Yes, I think a modern library should solve that
problem too.
Post by Matthew Woehlke
attribute idea? (In particular, because the parameter name given in an
attribute is quoted, it should not be subject to PP 'tampering'. This is
Yay.. I mean, eurgh. :)
Post by Matthew Woehlke
not the case with `.name` as in the original proposal.)
How so? I don't think you can #define .name whatever.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUb-5N1JAesthOWeRzCou8kOaXTL0dmT0d9pmP77v-8pDw%40mail.gmail.com.
Matthew Woehlke
2016-04-14 18:37:58 UTC
Permalink
Post by Ville Voutilainen
(In particular, because the parameter name given in an attribute is
quoted, it should not be subject to PP 'tampering'. This is not the
case with `.name` as in the original proposal.)
How so? I don't think you can #define .name whatever.
No, but if you `#define name oops`, `.name` will be replaced with
`.oops`. (There is a certain nasty case that recently bit me where
_GNU_SOURCE "adds" a pseudo-member to a system struct using exactly this
kludge; ugh. Also, I just checked¹ :-).)

(¹ `echo -e '#define foo bar\nnone(.foo = 5);' | gcc -E -`)
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/neoo26%249s3%241%40ger.gmane.org.
Tony V E
2016-04-14 21:19:21 UTC
Permalink
Post by Matthew Woehlke
‎Huh?
struct foo { int bar };
In C89, the "meaning" of this struct is that I can construct it like `{1}`. In C11, the "meaning" is that I can (additionally) construct it‎ like `{.bar=1}`. This was evidently not a problem for C11. What "change of meaning" occurs in C++ that is different from this example and therefore problematic?
In a struct, the member names are already part of the API.



Sent from my BlackBerry portable Babbage Device
  Original Message  
From: Matthew Woehlke
Sent: Thursday, April 14, 2016 11:57 AM
To: std-***@isocpp.org
Reply To: std-***@isocpp.org
Subject: [std-proposals] Re: [RFC] Uniform designated initializers and arguments for C++ (implementation available)
Post by Matthew Woehlke
Post by Matthew Woehlke
...but we were talking about *automatic* named parameters. We already
established that the parameter names don't matter currently, so why is
changing them to match an updated standard an issue?
Because I expect that in that newer standard they won't be uglified,
whereas they need to be when an older standard is used,
I don't get it. If parameter names don't matter in "old" C++, why must
the 'ugly' names be used? What am I missing?
Post by Matthew Woehlke
Post by Matthew Woehlke
[...] the meaning of the function declaration changes
...in what way? You keep asserting this, but I am not understanding what
change you think is occurring. I can only assume therefore that we
aren't talking about the same implementation.
int add(int [[named("a")] a, int [[named("b")]] b);
In both cases you have a function with the signature `int (int, int)`
(either because names aren't part of the type, or at least that decays
to that). In both cases, you can call the function like `add(2, 3);`.
All that has changed is that in one case you can *also* call it like
`add(.b = 3, .a = 2);`.
Well, duh, I can now also call the function like that because the meaning
of the function declaration changed. Had it not changed, I wouldn't be able
to call it that way.
Huh?

Let me try rephrasing this. Let's say we have a C struct:

struct foo { int bar };

In C89, the "meaning" of this struct is that I can construct it like
`{1}`. In C11, the "meaning" is that I can (additionally) construct it
like `{.bar=1}`. This was evidently not a problem for C11. What "change
of meaning" occurs in C++ that is different from this example and
therefore problematic?
Post by Matthew Woehlke
Post by Matthew Woehlke
The function/meaning of the parameter. For example, in `sin(double
.radians)`, the "user semantic" of `radians` is 'an angle in radians'.
If I want to rename that to `degrees`, it is a *feature* that this is an
API break, because the API did in fact change in a non-compatible
manner. This is different from "compiler semantic" because the compiler
(at least currently) has no way to diagnose if I pass degrees to a
function that expects radians, or vice versa.
In other words, you think you can make names have a "user semantic" if
named arguments are supported.
They would (when employed) become part of the public API in the same
manner as the function name, with similar issues arising if you want to
change the names. (In fact, I hadn't realized this before... the same
problems that would arise with renaming named parameters *already exist*
w.r.t. the name of the function itself. And yet, somehow we're managing.)
Post by Matthew Woehlke
That doesn't mean that all names have such
"user semantics", because currently none of them do, hence my confusion about
what these "user semantics" are. Today, they are a figment of imagination. With
named arguments, they might be a thing, although they might not be. I wouldn't
call that the strongest rationale for named arguments.
Ah... I think you perhaps misunderstand the intended scope. This
particular argument is not meant as an argument *for* named parameters,
only as an argument why the concern about "committing my API to a name"
is possibly overemphasized.
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/neoelk%249ko%241%40ger.gmane.org.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20160414211921.4902992.88470.9761%40gmail.com.
Thiago Macieira
2016-04-14 23:00:30 UTC
Permalink
Post by Tony V E
Post by Matthew Woehlke
‎Huh?
struct foo { int bar };
In C89, the "meaning" of this struct is that I can construct it like
`{1}`. In C11, the "meaning" is that I can (additionally) construct it‎
like `{.bar=1}`. This was evidently not a problem for C11. What "change
of meaning" occurs in C++ that is different from this example and
therefore problematic?
In a struct, the member names are already part of the API.
Kinda...

struct ip6_hdr
{
union
{
struct ip6_hdrctl
{
uint32_t ip6_un1_flow; /* 4 bits version, 8 bits TC,
20 bits flow-ID */
uint16_t ip6_un1_plen; /* payload length */
uint8_t ip6_un1_nxt; /* next header */
uint8_t ip6_un1_hlim; /* hop limit */
} ip6_un1;
uint8_t ip6_un2_vfc; /* 4 bits version, top 4 bits tclass */
} ip6_ctlun;
struct in6_addr ip6_src; /* source address */
struct in6_addr ip6_dst; /* destination address */
};

#define ip6_vfc ip6_ctlun.ip6_un2_vfc
#define ip6_flow ip6_ctlun.ip6_un1.ip6_un1_flow
#define ip6_plen ip6_ctlun.ip6_un1.ip6_un1_plen
#define ip6_nxt ip6_ctlun.ip6_un1.ip6_un1_nxt
#define ip6_hlim ip6_ctlun.ip6_un1.ip6_un1_hlim
#define ip6_hops ip6_ctlun.ip6_un1.ip6_un1_hlim

The API for this struct says
hdr.ip6_flow

but there's no member called "ip6_flow" in struct ip6_hdr.

See https://tools.ietf.org/html/rfc3542#section-2.1.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3549854.PvpFWvaERv%40tjmaciei-mobl4.
Patrice Roy
2016-04-15 00:14:08 UTC
Permalink
Thiago, this is an evil (but welcome!) example.

I read the proposal and I like it in general; in that area, it's among the
good ones.

Contrary to some, I've been quite often in a situation where changing
argument names in functions was important, and in situations where the
documentary names in a .h/.hpp file were different from the names used in
the function's implementation. I would be inclined to support a proposal
that showed how named arguments fit in with this reality of software
development.

I don't see named arguments as a «need», but they do look like a «want». We
do need a clear path to existing (and future, in this case, as argument
names can change anytime) code management. The attribute pathway is a no-go
(semantics) but does have a nice upside, which is separating the «interface
name» from the «implementation name»; this quality is not something to
throw away, IMHO.

Many have mentioned the C11 path, but C has no constructors, and C is a one
name, one function language. I'm not convinced it's a good basis for our
discussion.

Cheers! (and thanks to the author for bringing an old idea with a clear and
interesting presentation to make discussion meaningful)
Post by Thiago Macieira
Post by Tony V E
‎Huh?
struct foo { int bar };
In C89, the "meaning" of this struct is that I can construct it like
`{1}`. In C11, the "meaning" is that I can (additionally) construct it‎
like `{.bar=1}`. This was evidently not a problem for C11. What "change
of meaning" occurs in C++ that is different from this example and
therefore problematic?
In a struct, the member names are already part of the API.
Kinda...
struct ip6_hdr
{
union
{
struct ip6_hdrctl
{
uint32_t ip6_un1_flow; /* 4 bits version, 8 bits TC,
20 bits flow-ID */
uint16_t ip6_un1_plen; /* payload length */
uint8_t ip6_un1_nxt; /* next header */
uint8_t ip6_un1_hlim; /* hop limit */
} ip6_un1;
uint8_t ip6_un2_vfc; /* 4 bits version, top 4 bits tclass */
} ip6_ctlun;
struct in6_addr ip6_src; /* source address */
struct in6_addr ip6_dst; /* destination address */
};
#define ip6_vfc ip6_ctlun.ip6_un2_vfc
#define ip6_flow ip6_ctlun.ip6_un1.ip6_un1_flow
#define ip6_plen ip6_ctlun.ip6_un1.ip6_un1_plen
#define ip6_nxt ip6_ctlun.ip6_un1.ip6_un1_nxt
#define ip6_hlim ip6_ctlun.ip6_un1.ip6_un1_hlim
#define ip6_hops ip6_ctlun.ip6_un1.ip6_un1_hlim
The API for this struct says
hdr.ip6_flow
but there's no member called "ip6_flow" in struct ip6_hdr.
See https://tools.ietf.org/html/rfc3542#section-2.1.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3549854.PvpFWvaERv%40tjmaciei-mobl4
.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp1e7YBHBa327X4L35MbzPfPynr1HdHasH-S2D%3DvLdvfTA%40mail.gmail.com.
TONGARI J
2016-04-15 01:43:41 UTC
Permalink
Post by Patrice Roy
Thiago, this is an evil (but welcome!) example.
I read the proposal and I like it in general; in that area, it's among the
good ones.
I guess Thiago's example is an argument for designator list?
Post by Patrice Roy
Contrary to some, I've been quite often in a situation where changing
argument names in functions was important, and in situations where the
documentary names in a .h/.hpp file were different from the names used in
the function's implementation. I would be inclined to support a proposal
that showed how named arguments fit in with this reality of software
development.
That's allowed in my proposal, see my reply to Matthew
<https://groups.google.com/a/isocpp.org/d/msg/std-proposals/gtGWEUtATU4/G-WSyGRyBAAJ>
.
It's just a normal function redeclaration after all.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/461aca67-541c-4635-b37b-e97af281cb13%40isocpp.org.
Thiago Macieira
2016-04-15 04:13:16 UTC
Permalink
Post by TONGARI J
I guess Thiago's example is an argument for designator list?
It's an argument against "member names are part of the API". However, this
*does* work in C99:

struct ip6_hdr hdr = {
.ip6_flow = 0,
.ip6_plen = 4,
.ip6_nxt = 46,
.ip6_hops = 64
};
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3634317.zkgPMoJp7T%40tjmaciei-mobl4.
Matthew Woehlke
2016-04-15 14:37:14 UTC
Permalink
Post by Tony V E
Post by Matthew Woehlke
struct foo { int bar };
In C89, the "meaning" of this struct is that I can construct it
like `{1}`. In C11, the "meaning" is that I can (additionally)
construct it‎ like `{.bar=1}`. This was evidently not a problem for
C11. What "change of meaning" occurs in C++ that is different from
this example and therefore problematic?
In a struct, the member names are already part of the API.
That's not relevant. Remember, this was talking about an opt-in approach
using attributes. This would mean that in C++11, the parameter names are
*also* already part of the API; they're just not an *accessible* part
(the attribute is there, but ignored because it isn't recognized by
C++11). This is almost exactly the same as in C89, the member names are
"already part" of the initializer list; you just can't use them.

Example:

int foo(int [[named("x")]]);

Note that the parameter name "x" is *already part of the API* (although
not a recognized part by C++11). In C++11, I can call `foo(5)`, just
like in C89 I can construct my struct like `{5}`. In C++??¹ I can *also*
call `foo(.x = 5)`... again, just like in C11 I can also construct my
struct like `{.bar = 5}`.

I have yet to meet a non-hand-waving argument argument why the C89->C11
change is okay but the C++11->C++?? change is not.

(¹ C++?? -> a hypothetical version of C++ that includes this feature.)
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nequb8%24933%241%40ger.gmane.org.
Thiago Macieira
2016-04-15 16:50:44 UTC
Permalink
Post by Matthew Woehlke
That's not relevant. Remember, this was talking about an opt-in approach
using attributes.
I recommend you stop talking about attributes, as this lowers the chance of
the feature being accepted. Not only would the feature itself be fighting to
prove its worth (it's been rejected more than once), using attributes means
fighting against established rules over attributes.

Remember that this feature is asking for differences in overload resolution
and has consequences for the ABI. That's way outside what attributes are meant
to do.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/91376508.yeYmejBR2X%40tjmaciei-mobl4.
Matthew Woehlke
2016-04-15 17:29:32 UTC
Permalink
Post by Thiago Macieira
I recommend you stop talking about attributes, as this lowers the chance of
the feature being accepted. Not only would the feature itself be fighting to
prove its worth (it's been rejected more than once), using attributes means
fighting against established rules over attributes.
Remember that this feature is asking for differences in overload resolution
and has consequences for the ABI. That's way outside what attributes are meant
to do.
It *doesn't* have consequences for the ABI; Tongari has been rather
explicit on this point. I suspect it isn't "asking for differences in
overload resolution" either; not, at least, in the sense I suspect you
are thinking.

Note:

int foo(int .a);
int foo(int); // same as previous
int foo(int .b); // error

I'm starting to think that the problem is that folks are interpreting
conversations based on the features and drawbacks of their own pet
implementation, rather than the variation actually being discussed in a
particular conversation thread.
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ner8dt%243n4%241%40ger.gmane.org.
TONGARI J
2016-04-15 17:37:59 UTC
Permalink
Post by Thiago Macieira
Post by Thiago Macieira
I recommend you stop talking about attributes, as this lowers the chance
of
Post by Thiago Macieira
the feature being accepted. Not only would the feature itself be
fighting to
Post by Thiago Macieira
prove its worth (it's been rejected more than once), using attributes
means
Post by Thiago Macieira
fighting against established rules over attributes.
Remember that this feature is asking for differences in overload
resolution
Post by Thiago Macieira
and has consequences for the ABI. That's way outside what attributes are
meant
Post by Thiago Macieira
to do.
It *doesn't* have consequences for the ABI; Tongari has been rather
explicit on this point. I suspect it isn't "asking for differences in
overload resolution" either; not, at least, in the sense I suspect you
are thinking.
To be clear, it doesn't affect function overloading but does add a new step
in overload resolution process (i.e. argument-mapping).
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANCwVhch4z_AWn_szkp%2B-ztWXkuBxtQdPu%2B79bryG3CGjcaPMw%40mail.gmail.com.
Thiago Macieira
2016-04-15 21:26:30 UTC
Permalink
Post by Matthew Woehlke
It *doesn't* have consequences for the ABI; Tongari has been rather
explicit on this point. I suspect it isn't "asking for differences in
overload resolution" either; not, at least, in the sense I suspect you
are thinking.
int foo(int .a);
int foo(int); // same as previous
int foo(int .b); // error
I'm starting to think that the problem is that folks are interpreting
conversations based on the features and drawbacks of their own pet
implementation, rather than the variation actually being discussed in a
particular conversation thread.
Fair enough. I haven't paid enough attention to this thread, but I've seen
several times code like this going around:

complex<double> make_complex(double .real, double .imag);
complex<double> make_complex(double .magnitude, double .argument);

Still, attributes are the wrong solution for this.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2518975.6yXMB68uC6%40tjmaciei-mobl4.
TONGARI J
2016-04-14 15:49:58 UTC
Permalink
Not if we don't allow overloading on names?²
// header
int foo(int [[named("bar")]] maybe_bar);
// implementation
int foo(int not_bar) // note: API name not repeated
{ ... }
Out of curious, why bother to specify maybe_bar in the header? Is the name
used anywhere?

FWIW, in my proposal, this is allowed:

int foo(int .bar);
int foo(int not_bar);

But this is not:

int foo(int .bar);
int foo(int .not_bar);

section 5.6
<http://jamboree.github.io/designator-draft.html#56-why-not-allow-parameter-name-based-overloading> gave
some rationale. What Tony V.E described is path 1, and what Richard
Smith described is path 2.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6ea2b03c-445d-4dc2-a9f7-e359a480dcaf%40isocpp.org.
Matthew Woehlke
2016-04-14 16:01:24 UTC
Permalink
Post by TONGARI J
Post by Matthew Woehlke
// header
int foo(int [[named("bar")]] maybe_bar);
// implementation
int foo(int not_bar) // note: API name not repeated
{ ... }
Out of curious, why bother to specify maybe_bar in the header?
Purely for illustrative purposes. I wanted to show that the
implementation name in a declaration can be different from the
implementation name in the definition. I could also have omitted it
entirely.
Post by TONGARI J
int foo(int .bar);
int foo(int not_bar);
Cool :-). FWIW, I think that's a good approach.
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/neoesl%24dd9%241%40ger.gmane.org.
TONGARI J
2016-04-14 03:26:55 UTC
Permalink
Post by Matthew Woehlke
A much bigger hurdle is having this proposal survive five minutes
after its presentation, because the previous ones dropped dead in
about that time.
1) a "both sides must opt in" proposal comes in. The response is
"this doesn't help anyone in the near future, and makes function
declarations more complex, for questionable benefit.
Would it be the end of the world to make the following be synonymous?
int square(int .x);
int square([[named("x")]] int);
int square([[named("x")]] int not_x);
I realize that attributes with meaning aren't loved, but the advantage
this has is addressing the 'not useful *now*' complaint, by making it
possible to write code (without using macros) that can be compiled with
a C++11 compiler that still provides named arguments when used with a
newer compiler. It also addresses the standard library to some extent,
as it permits adding named arguments to the API while still allowing the
implementation to use whatever it wants for names.
Why not macros? Is the following really that bad?

#if has_designatable_parameters
#define NAMED_PARAM(p) .p
#else
#define NAMED_PARAM(p) p
#endif

void f(int NAMED_PARAM(a)); // use it now
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/09493752-1475-4bc1-9b29-ec447c309339%40isocpp.org.
Matthew Woehlke
2016-04-14 14:22:12 UTC
Permalink
Post by TONGARI J
Why not macros? Is the following really that bad?
#if has_designatable_parameters
#define NAMED_PARAM(p) .p
#else
#define NAMED_PARAM(p) p
#endif
Yes. You have to either undefine this macro after use, or prefix it with
something unique. Remember, you're talking about a library that may be
one of many libraries used by an application, all of which want to use
such a macro, and all of which have their own subtly different version
thereof. (The only reasonable way around this might be to have the macro
specified by the standard, with the proviso that users may define it -
with a specified definition - if it is not defined.)

Also, don't discount being able to give the parameter different names in
the API vs. the implementation. Or people that just plain hate macros.
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/neo92k%242go%242%40ger.gmane.org.
b***@gmail.com
2016-04-13 21:13:54 UTC
Permalink
Post by Ville Voutilainen
2) a "works automatically" proposal comes in. The response is "well,
that doesn't work with the standard library,
and authors of other libraries don't want to have the introduced
requirement to provide stable names without their opt-in,
so <insert the work-arounds again>..."
Is that really the argument against "works automatically"? Library authors
could simply not document/advertise those names (i.e. use those at your own
risk). Keeping argument names stable doesn't strike me as more burdensome
than keep everything else stable. How often do you change an argument name,
but nothing else?

Besides, Python has had this ability for years and been *wildly *successful
at sharing libraries.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c0aec269-80bb-4c27-b01d-81eb323e35af%40isocpp.org.
Ville Voutilainen
2016-04-13 21:23:41 UTC
Permalink
Post by b***@gmail.com
Post by Ville Voutilainen
2) a "works automatically" proposal comes in. The response is "well,
that doesn't work with the standard library,
and authors of other libraries don't want to have the introduced
requirement to provide stable names without their opt-in,
so <insert the work-arounds again>..."
Is that really the argument against "works automatically"?
Well, considering that it was an argument that was raised when discussing
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4172.htm,
sure, it's an argument against "works automatically". Whether you agree with
that argument is a separate matter.
Post by b***@gmail.com
Library authors could simply not document/advertise those names (i.e. use those at your own
risk). Keeping argument names stable doesn't strike me as more burdensome
than keep everything else stable. How often do you change an argument name,
but nothing else?
Based on the arguments made when discussing the aforementioned paper,
depending on who you
ask, the answers are 1) that will not work 2) it is more burdensome
and 3) often enough to oppose
such a proposal.
Post by b***@gmail.com
Besides, Python has had this ability for years and been wildly successful at
sharing libraries.
Yeah, but the argument is that C++ library writers know that they
don't need to deal with it, and don't want
it imposed on them, and then we go back to "both sides opt in" which
will not work with the standard library,
because unlike python and lisp, the argument names are not standardized in C++.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUa4_rUAhUnJzw%3DHZ%2B_sWYJVs43LszOF80D22o2fMrPmhA%40mail.gmail.com.
TONGARI J
2016-04-14 03:20:01 UTC
Permalink
Post by Ville Voutilainen
Post by b***@gmail.com
Post by Ville Voutilainen
2) a "works automatically" proposal comes in. The response is "well,
that doesn't work with the standard library,
and authors of other libraries don't want to have the introduced
requirement to provide stable names without their opt-in,
so <insert the work-arounds again>..."
Is that really the argument against "works automatically"?
Well, considering that it was an argument that was raised when discussing
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4172.htm,
sure, it's an argument against "works automatically". Whether you agree with
that argument is a separate matter.
Post by b***@gmail.com
Library authors could simply not document/advertise those names (i.e.
use those at your own
Post by b***@gmail.com
risk). Keeping argument names stable doesn't strike me as more
burdensome
Post by b***@gmail.com
than keep everything else stable. How often do you change an argument
name,
Post by b***@gmail.com
but nothing else?
Based on the arguments made when discussing the aforementioned paper,
depending on who you
ask, the answers are 1) that will not work 2) it is more burdensome
and 3) often enough to oppose
such a proposal.
Post by b***@gmail.com
Besides, Python has had this ability for years and been wildly
successful at
Post by b***@gmail.com
sharing libraries.
Yeah, but the argument is that C++ library writers know that they
don't need to deal with it, and don't want
it imposed on them, and then we go back to "both sides opt in" which
will not work with the standard library,
because unlike python and lisp, the argument names are not standardized in C++.
Do you mean the argument names cannot be standardized in the future? why?
I don't see any problem with the opt-in model I proposed, as I suggested in
section 4.1.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b787b0e5-9562-4b92-9a77-75c1bd1ca1ba%40isocpp.org.
Andrey Semashev
2016-04-13 21:21:36 UTC
Permalink
Post by Richard Smith
This looks more or less like how I'd always imagined designated
initializers would work in C++. Thanks for writing this! One question,
"3.2.1.1 Function redeclaration
If a function is declared with designatable parameters and/or default
arguments, it cannot be redeclared with designatable parameters and/or
default arguments, otherwise, the program is ill-formed."
a) every declaration of the same function must specify the same
designatable parameters, with the same names, and
b) perhaps overloading on designated parameter names should be permitted
struct my_complex {
my_complex(double .rho, double .theta);
my_complex(double .real, double .imag);
};
Here, these constructors could *only* be called with designated
parameter names, because any non-designated call would be ambiguous.
I don't think this is a good idea. If those were two functions, there
would be no way to resolve the ambiguity when taking an address of the
function.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/abd1385f-dfeb-cee2-184d-d5f6936896fa%40gmail.com.
Tony V E
2016-04-13 21:42:46 UTC
Permalink
‎0. Naming is hard. 

Something to consider: how would I later rename a param? Particularly once users have started ‎using the old name and I don't want to break them.  

I could rename the whole function, but see #0 above. (and if it is the constructor, do I rename the whole class?)

So it might be nice to allow ways to overload, even if the overload just turns around and calls the original:

‎my_complex(double .real, double .imag);
// whoops! Coding guidelines say no short forms
my_complex(doule .real, double .imaginary) ;



Sent from my BlackBerry portable Babbage Device
  Original Message  
From: Andrey Semashev
Sent: Wednesday, April 13, 2016 5:21 PM
To: std-***@isocpp.org
Reply To: std-***@isocpp.org
Subject: Re: [std-proposals] [RFC] Uniform designated initializers and arguments for C++ (implementation available)
Post by Richard Smith
This looks more or less like how I'd always imagined designated
initializers would work in C++. Thanks for writing this! One question,
"3.2.1.1 Function redeclaration
If a function is declared with designatable parameters and/or default
arguments, it cannot be redeclared with designatable parameters and/or
default arguments, otherwise, the program is ill-formed."
a) every declaration of the same function must specify the same
designatable parameters, with the same names, and
b) perhaps overloading on designated parameter names should be permitted
struct my_complex {
my_complex(double .rho, double .theta);
my_complex(double .real, double .imag);
};
Here, these constructors could *only* be called with designated
parameter names, because any non-designated call would be ambiguous.
I don't think this is a good idea. If those were two functions, there
would be no way to resolve the ambiguity when taking an address of the
function.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/abd1385f-dfeb-cee2-184d-d5f6936896fa%40gmail.com.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20160413214246.4907089.83410.9691%40gmail.com.
Matthew Woehlke
2016-04-14 14:32:12 UTC
Permalink
Post by Tony V E
‎0. Naming is hard.
Yup :-).
Post by Tony V E
Something to consider: how would I later rename a param? Particularly once users have started ‎using the old name and I don't want to break them.
I could rename the whole function, but see #0 above. (and if it is the constructor, do I rename the whole class?)
‎my_complex(double .real, double .imag);
// whoops! Coding guidelines say no short forms
my_complex(doule .real, double .imaginary) ;
If this is the *only* case of renaming you want to support (i.e. same
functions with "options" for names), you could easily extend my
attribute idea to do that. Even better:

my_complex(
double
[[named("real")]]
p_u,
double
[[deprecated]] [[named("imag")]]
[[named("imaginary")]]
p_v);

(Syntax definitely needs some love, but you get the idea... and I was
even able to make the old name deprecated, so code using it will emit a
warning! Yes, I can do that with your version also, but the warning will
be slightly more specific with mine, as the compiler can tell you
specifically that a parameter name is what is deprecated and can suggest
the replacement name. For a case like this where the code semantics
haven't changed, it would even be fairly easy to write a tool to
automatically "update" user code.)
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/neo9lc%24g2r%241%40ger.gmane.org.
Richard Smith
2016-04-14 00:38:36 UTC
Permalink
Post by Andrey Semashev
Post by Richard Smith
This looks more or less like how I'd always imagined designated
initializers would work in C++. Thanks for writing this! One question,
"3.2.1.1 Function redeclaration
If a function is declared with designatable parameters and/or default
arguments, it cannot be redeclared with designatable parameters and/or
default arguments, otherwise, the program is ill-formed."
a) every declaration of the same function must specify the same
designatable parameters, with the same names, and
b) perhaps overloading on designated parameter names should be permitted
struct my_complex {
my_complex(double .rho, double .theta);
my_complex(double .real, double .imag);
};
Here, these constructors could *only* be called with designated
parameter names, because any non-designated call would be ambiguous.
I don't think this is a good idea. If those were two functions, there
would be no way to resolve the ambiguity when taking an address of the
function.
Note that I'm also in favour of designatable parameter names being part of
the function type. With that change, this would work the same as any other
overload / address of function situation.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3Dcwvf2bamvSHMruSpio3inaOkfGDYD6Z43Y7MgZz7gDQ%40mail.gmail.com.
TONGARI J
2016-04-14 03:09:54 UTC
Permalink
Hi Richard,
Post by Richard Smith
This looks more or less like how I'd always imagined designated
initializers would work in C++. Thanks for writing this! One question, you
"3.2.1.1 Function redeclaration
If a function is declared with designatable parameters and/or default
arguments, it cannot be redeclared with designatable parameters and/or
default arguments, otherwise, the program is ill-formed."
a) every declaration of the same function must specify the same
designatable parameters, with the same names, and
b) perhaps overloading on designated parameter names should be permitted
struct my_complex {
my_complex(double .rho, double .theta);
my_complex(double .real, double .imag);
};
Here, these constructors could *only* be called with designated parameter
names, because any non-designated call would be ambiguous.
There are some principles I set when designing the feature:
* Don't interfere with the type system
* Don't require ABI changes
* Don't complicate the function declaration

I did consider allowing multiple function declarations with different
designators in early stage, but the idea soon got dropped.
The idea was different from what you would expect though:
void f(int .a, int .b);
void f(int .x, int .y);

The 2 declarations will be the *same* function, not 2 overloads. This may
be useful in some case but also confusing and may complicate the
implementation so I dropped it.

As for allowing multiple identical declarations, my argument against it is
for consistency, consider default arguments:
void f(int a = 1);
void f(int a = 1);

It's not allowed even though the 2 are lexically identical, and I think the
same should apply to designatable parameters as well.

What you suggested in the my_complex example is to make them overloads,
which is a design decision I don't want to take in this proposal.
Post by Richard Smith
Have you considered the interaction of this proposal with forwarding
functions and with types like std::function? I would find it problematic if
correct forwarding is not possible for functions with designated
parameters. I think you will encounter resistance if something like this is
void f(int .foo, int .bar);
std::function<void(int .foo, int .bar)> fn = f;
fn(.bar = 1, .foo = 2);
(a) designated parameter names to become part of a function type, and
(b) add a way to write a function template that accepts a pack of
designated parameters, capturing both the names and the values, and
allowing both to be used when forwarding
But (b) in particular seems like it would add a lot of complexity. I hope
there's a better alternative.
Actually, forwarding function is explicitly listed in my non-goals, that's
why I deliberately disable the indirect use in the end of section 3.2.3.

If I were going to support forwarding functions, that means I have to make
designatable parameters part of the type as you suggested in (a), and that
breaks my design principles.
My choice for designated arguments is much like parameter pack, that is,
don't make them first class objects.

I should emphasize how reluctant I am in interfering with the type system -
it's a no-go for me if adding designatable parameters to existing API would
break the ABI.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/394c670e-6339-4933-abba-8f6d950dff47%40isocpp.org.
Richard Smith
2016-04-14 17:57:25 UTC
Permalink
Post by TONGARI J
Hi Richard,
Post by Richard Smith
This looks more or less like how I'd always imagined designated
initializers would work in C++. Thanks for writing this! One question, you
"3.2.1.1 Function redeclaration
If a function is declared with designatable parameters and/or default
arguments, it cannot be redeclared with designatable parameters and/or
default arguments, otherwise, the program is ill-formed."
a) every declaration of the same function must specify the same
designatable parameters, with the same names, and
b) perhaps overloading on designated parameter names should be permitted
struct my_complex {
my_complex(double .rho, double .theta);
my_complex(double .real, double .imag);
};
Here, these constructors could *only* be called with designated parameter
names, because any non-designated call would be ambiguous.
* Don't interfere with the type system
Please allow me to suggest an alternative principle: integrate into the
existing language.

Far too often, people proposing features make the mistake of making their
feature be its own special island that has rules different from the rest of
the language. This is a trap to be avoided. Language continuity is
important: C++20 should look and feel like a development of C++17, in order
to make it easier for programmers and programs to adapt, but we don't get
there by minimizing the amount of change to the language or specification,
we get there by making the changes complete so they feel like an extension
of what came before.

A feature that does not integrate into the type system, but whose design
would naturally lead to type system changes, is flawed. In my opinion, you
should first design the feature, and then analyze the type system
implications, not the other way around. (And if that leads to no type
system changes, that's fine, of course.)

* Don't require ABI changes
I think you should distinguish between "don't change the ABI of existing
libraries" and "don't change the ABI when designated parameters are added
to an interface". The first seems like an important principle. The second,
less so -- as long as the library maintainer still gets to control their
ABI as they see fit.
Post by TONGARI J
* Don't complicate the function declaration
I did consider allowing multiple function declarations with different
designators in early stage, but the idea soon got dropped.
void f(int .a, int .b);
void f(int .x, int .y);
The 2 declarations will be the *same* function, not 2 overloads. This may
be useful in some case but also confusing and may complicate the
implementation so I dropped it.
As for allowing multiple identical declarations, my argument against it is
void f(int a = 1);
void f(int a = 1);
It's not allowed even though the 2 are lexically identical, and I think
the same should apply to designatable parameters as well.
What you suggested in the my_complex example is to make them overloads,
which is a design decision I don't want to take in this proposal.
Post by Richard Smith
Have you considered the interaction of this proposal with forwarding
functions and with types like std::function? I would find it problematic if
correct forwarding is not possible for functions with designated
parameters. I think you will encounter resistance if something like this is
void f(int .foo, int .bar);
std::function<void(int .foo, int .bar)> fn = f;
fn(.bar = 1, .foo = 2);
(a) designated parameter names to become part of a function type, and
(b) add a way to write a function template that accepts a pack of
designated parameters, capturing both the names and the values, and
allowing both to be used when forwarding
But (b) in particular seems like it would add a lot of complexity. I hope
there's a better alternative.
Actually, forwarding function is explicitly listed in my non-goals, that's
why I deliberately disable the indirect use in the end of section 3.2.3.
The fact that this is a non-goal is going to make your proposal very
unappealing to some portion of the committee.
Post by TONGARI J
If I were going to support forwarding functions, that means I have to make
designatable parameters part of the type as you suggested in (a), and that
breaks my design principles.
My choice for designated arguments is much like parameter pack, that is,
don't make them first class objects.
I should emphasize how reluctant I am in interfering with the type system
- it's a no-go for me if adding designatable parameters to existing API
would break the ABI.
Adding parameters with default arguments to existing API would break the
ABI too, as would many other API changes. With a suitable overload
resolution rule, I'd expect to be able to change an API that does this:

struct A {
void f(int a, int b);
};

... to do this:

struct A {
void f(int a, int b);
void f(int .a, int .b) { f(a, b); }
};

... as a non-breaking change (except if someone is taking the address of
the function), for people who need perfect ABI compatibility.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqkL-hpY2KMY8JGGk6KZ3ApDqtZvKCaJeFe0Z5fnFdd13g%40mail.gmail.com.
Matthew Woehlke
2016-04-14 18:54:02 UTC
Permalink
Post by Richard Smith
Adding parameters with default arguments to existing API would break the
ABI too, as would many other API changes. With a suitable overload
struct A {
void f(int a, int b);
};
struct A {
void f(int a, int b);
void f(int .a, int .b) { f(a, b); }
};
... as a non-breaking change (except if someone is taking the address of
the function), for people who need perfect ABI compatibility.
I'd expect that this:

struct A {
void f(int .a, int .b);
};

...is a (mostly?¹) non-breaking change. Yes, function pointer and all;
*if* named parameters are part of the function type, then IMO the
respective pointer types should implicitly decay to pointers with fewer
named arguments. IOW:

int f(int .a, int .b);
int (*p1)(int .a, int .b) = &f; // okay
int (*p2)(int, int .b) = &f; // also okay
int (*p3)(int, int) = &f; // also okay

int g(int .a, int .b);
int g(int .x, int .y);
int (*p4)(int .a, int .b) = &g; // okay
int (*p5)(int, int .b) = &g; // still okay
int (*p6)(int, int) = &g; // error: ambiguous
int (*p7)(int, int) = p4; // okay

(¹ There might be cases where the change in type of the function pointer
breaks something, but not just due to trying to feed it to something
that expects the no-named-parameters pointer type.)

However, I'll mention again that IMO there are non-trivial issues
including parameter names in the type system, and that the language most
commonly cited for supporting named parameters (Python) *doesn't allow
overloading* (at all). Also, that most cases that come to mind where
you'd want it seem better solved with strong type aliases. This causes
me to strongly question the value of including parameter names in the
type system.
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/neop0a%24n8b%241%40ger.gmane.org.
Farid Mehrabi
2016-04-14 19:52:36 UTC
Permalink
​Feels like designated initialization of ​POD types is less controversial,
more conservative, yet more elegant than expected.
For naming function arguments one might wrap it in a function object:

struct caller;
void caller::operator()()
{
f(x,y);
};
caller{.x=1,.y=2}();

or even shorter:

struct caller;
caller::~caller()
{
f(x,y);
};
caller{.x=1,.y=2};

Of Course it doesn't cover every corner case of function calls such as
constructor with named args(eg. std::vector::vector or
std::complex::complex).

For constructors I would rather put all args in a POD type:

std::complex<double> c1{ polar{ .magnitude=1.0, .angle=degree(30) } };
std::complex<double> c1{ cartesian{ .real=1.0, .image=1.0 } };

I agree that this is not as sweat as functions with named variables.

Another more fundamental problem with types is that uninitialized members
will try to use implicit default constructors. This might partially be
overcome by forcing the programmer to explicitly initialize members:

struct bar{
//new syntax:
explicit int x;// explicitly initialized
int y; // don't care about y
};

bar b1{1,2}; //ok
bar b2{.x=2};//ok
bar b3; //compile error: x not initialized

or even stricter:

//new syntax:
explicit struct foo //every member is explicitly initialized, except if
defaulted
{
int x;
int y=1; // y has default value
};

foo f1{.x=0}; //ok
foo f2{.y=2,.x=0}; //ok
foo f3; //compile error: x not initialized

regards,
FM.
Post by Richard Smith
Post by Richard Smith
Adding parameters with default arguments to existing API would break the
ABI too, as would many other API changes. With a suitable overload
struct A {
void f(int a, int b);
};
struct A {
void f(int a, int b);
void f(int .a, int .b) { f(a, b); }
};
... as a non-breaking change (except if someone is taking the address of
the function), for people who need perfect ABI compatibility.
struct A {
void f(int .a, int .b);
};
...is a (mostly?¹) non-breaking change. Yes, function pointer and all;
*if* named parameters are part of the function type, then IMO the
respective pointer types should implicitly decay to pointers with fewer
int f(int .a, int .b);
int (*p1)(int .a, int .b) = &f; // okay
int (*p2)(int, int .b) = &f; // also okay
int (*p3)(int, int) = &f; // also okay
int g(int .a, int .b);
int g(int .x, int .y);
int (*p4)(int .a, int .b) = &g; // okay
int (*p5)(int, int .b) = &g; // still okay
int (*p6)(int, int) = &g; // error: ambiguous
int (*p7)(int, int) = p4; // okay
(¹ There might be cases where the change in type of the function pointer
breaks something, but not just due to trying to feed it to something
that expects the no-named-parameters pointer type.)
However, I'll mention again that IMO there are non-trivial issues
including parameter names in the type system, and that the language most
commonly cited for supporting named parameters (Python) *doesn't allow
overloading* (at all). Also, that most cases that come to mind where
you'd want it seem better solved with strong type aliases. This causes
me to strongly question the value of including parameter names in the
type system.
--
Matthew
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/neop0a%24n8b%241%40ger.gmane.org
.
--
how am I supposed to end the twisted road of your hair in such a dark
night??
unless the candle of your face does shed some light upon my way!!!
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALDL7dGM%2BKX5BK0%3DQioxu04_zzvbgiGWU2V5b%3DaRyBnBpXVWXg%40mail.gmail.com.
TONGARI J
2016-04-15 02:17:20 UTC
Permalink
Post by Richard Smith
Post by TONGARI J
* Don't interfere with the type system
Please allow me to suggest an alternative principle: integrate into the
existing language.
Well, it does integrate into the existing language.
I know what I want for this feature, and smooth adoption w/o binary
incompatibility is what I desire, hence the principle.
Post by Richard Smith
Far too often, people proposing features make the mistake of making their
feature be its own special island that has rules different from the rest of
the language. This is a trap to be avoided. Language continuity is
important: C++20 should look and feel like a development of C++17, in order
to make it easier for programmers and programs to adapt, but we don't get
there by minimizing the amount of change to the language or specification,
we get there by making the changes complete so they feel like an extension
of what came before.
A feature that does not integrate into the type system, but whose design
would naturally lead to type system changes, is flawed. In my opinion, you
should first design the feature, and then analyze the type system
implications, not the other way around. (And if that leads to no type
system changes, that's fine, of course.)
* Don't require ABI changes
I think you should distinguish between "don't change the ABI of existing
libraries" and "don't change the ABI when designated parameters are added
to an interface". The first seems like an important principle. The second,
less so -- as long as the library maintainer still gets to control their
ABI as they see fit.
I have a feeling that there would be a resistance to adopt designatable
parameters because of ABI incompatibility.
Post by Richard Smith
Actually, forwarding function is explicitly listed in my non-goals, that's
Post by TONGARI J
why I deliberately disable the indirect use in the end of section 3.2.3.
The fact that this is a non-goal is going to make your proposal very
unappealing to some portion of the committee.
Post by TONGARI J
If I were going to support forwarding functions, that means I have to
make designatable parameters part of the type as you suggested in (a), and
that breaks my design principles.
My choice for designated arguments is much like parameter pack, that is,
don't make them first class objects.
I should emphasize how reluctant I am in interfering with the type system
- it's a no-go for me if adding designatable parameters to existing API
would break the ABI.
Adding parameters with default arguments to existing API would break the
ABI too
I don't see any difference in the generated LLVM IR with or without default
arguments, any example how it affects the ABI?

as would many other API changes. With a suitable overload resolution rule,
Post by Richard Smith
struct A {
void f(int a, int b);
};
struct A {
void f(int a, int b);
void f(int .a, int .b) { f(a, b); }
};
... as a non-breaking change (except if someone is taking the address of
the function), for people who need perfect ABI compatibility.
So call A{}.f(0, 1)is ruled by some conversion sequence?

What about:
void f(int .a, int .b);
void f(int .b, int .a);

Is the overload valid? Is f(.a = 0, .b = 1) ambiguous?

And how would you forward the designators for, say, std::function?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5a3ebaf4-5297-43d5-9de4-69566c841592%40isocpp.org.
Richard Smith
2016-04-15 02:42:15 UTC
Permalink
Post by TONGARI J
Post by Richard Smith
Post by TONGARI J
* Don't interfere with the type system
Please allow me to suggest an alternative principle: integrate into the
existing language.
Well, it does integrate into the existing language.
I know what I want for this feature, and smooth adoption w/o binary
incompatibility is what I desire, hence the principle.
Post by Richard Smith
Far too often, people proposing features make the mistake of making their
feature be its own special island that has rules different from the rest of
the language. This is a trap to be avoided. Language continuity is
important: C++20 should look and feel like a development of C++17, in order
to make it easier for programmers and programs to adapt, but we don't get
there by minimizing the amount of change to the language or specification,
we get there by making the changes complete so they feel like an extension
of what came before.
A feature that does not integrate into the type system, but whose design
would naturally lead to type system changes, is flawed. In my opinion, you
should first design the feature, and then analyze the type system
implications, not the other way around. (And if that leads to no type
system changes, that's fine, of course.)
* Don't require ABI changes
I think you should distinguish between "don't change the ABI of existing
libraries" and "don't change the ABI when designated parameters are added
to an interface". The first seems like an important principle. The second,
less so -- as long as the library maintainer still gets to control their
ABI as they see fit.
I have a feeling that there would be a resistance to adopt designatable
parameters because of ABI incompatibility.
Post by Richard Smith
Actually, forwarding function is explicitly listed in my non-goals,
Post by TONGARI J
that's why I deliberately disable the indirect use in the end of section
3.2.3.
The fact that this is a non-goal is going to make your proposal very
unappealing to some portion of the committee.
Post by TONGARI J
If I were going to support forwarding functions, that means I have to
make designatable parameters part of the type as you suggested in (a), and
that breaks my design principles.
My choice for designated arguments is much like parameter pack, that is,
don't make them first class objects.
I should emphasize how reluctant I am in interfering with the type
system - it's a no-go for me if adding designatable parameters to existing
API would break the ABI.
Adding parameters with default arguments to existing API would break the
ABI too
I don't see any difference in the generated LLVM IR with or without
default arguments, any example how it affects the ABI?
"void f(int a);" and "void f(int a, int b = 0);" generate different code.
The point is that we only need to provide tools to avoid ABI breaks, we
don't need to make sure that using the feature doesn't break ABI. That's up
to the library vendor to deal with.
Post by TONGARI J
as would many other API changes. With a suitable overload resolution
Post by Richard Smith
struct A {
void f(int a, int b);
};
struct A {
void f(int a, int b);
void f(int .a, int .b) { f(a, b); }
};
... as a non-breaking change (except if someone is taking the address of
the function), for people who need perfect ABI compatibility.
So call A{}.f(0, 1)is ruled by some conversion sequence?
Sure.
Post by TONGARI J
void f(int .a, int .b);
void f(int .b, int .a);
Is the overload valid? Is f(.a = 0, .b = 1) ambiguous?
Yes, ambiguous.
Post by TONGARI J
And how would you forward the designators for, say, std::function?
I asked you the same question upthread :) I also sketched out one possible
approach.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqkREWaKKZ-3skHEDrp3kZW%3D5X2c-0n-OLOdStPAYMEPYw%40mail.gmail.com.
TONGARI J
2016-04-15 06:01:21 UTC
Permalink
Post by Richard Smith
Post by TONGARI J
And how would you forward the designators for, say, std::function?
I asked you the same question upthread :) I also sketched out one possible
approach.
template<typename F, designator ...D, typename ...T> decltype(auto) f(F f,
T &&... .D) {
return f(0, .D = std::forward<T>(D) ...);
}
That is: a new kind of template parameter representing a designator, and
designator names are looked up to see if they name such a parameter before
assuming they're an opaque identifier. (Plus a notional "empty designator"
that is deduced in cases where no designator is specified.) I don't think I
like this approach, and as noted, I hope there's a better answer.
I imagine a more proper syntax would be:

template<designator ...D, typename F, typename ...T> decltype(auto) call(F f
, T && D ...t) {
return f(0, D = std::forward<T>(t) ...);
}

* "designator" would be a contextual keyword only allowed in template
param-list.
* The designators can be used in both param-list in
the function declaration (isolated from the actual param-name) and the
expr-list in function-call-expr.

However, I'm not sure if you could deduce the designators from args or not?
call(f, .b = 1, .a = 2); // ok?

If you allow the call above, what if call is defined as below:
template<typename F, typename ...T> decltype(auto) call(F f, T && ...t) {
return f(0, std::forward<T>(t) ...);
}
Should it give the same result?

I suspect you cannot do that. A simpler way is to force designators to be
explicitly specified:
call<.a, .b>(f, .b = 1, .a = 2);

I'm not sure I like it though, seems problematic if we're going to support
designated template arguments in the future, e.g. V<.T = int>.

You really think it worth the complexity?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/98475b72-820c-4eaf-a530-a9ebd02d09f4%40isocpp.org.
Richard Smith
2016-04-13 20:58:43 UTC
Permalink
Post by TONGARI J
Hi,
http://jamboree.github.io/designator-draft.html
https://github.com/jamboree/clang/tree/feature/designator
Have you considered the interaction of this proposal with forwarding
functions and with types like std::function? I would find it problematic if
correct forwarding is not possible for functions with designated
parameters. I think you will encounter resistance if something like this is
not possible, and we have no known path forward to support it:

void f(int .foo, int .bar);
std::function<void(int .foo, int .bar)> fn = f;
fn(.bar = 1, .foo = 2);

One possible way to make this work could be:
(a) designated parameter names to become part of a function type, and
(b) add a way to write a function template that accepts a pack of
designated parameters, capturing both the names and the values, and
allowing both to be used when forwarding
But (b) in particular seems like it would add a lot of complexity. I hope
there's a better alternative.
Post by TONGARI J
I'm not sure if it's proper to submit a new proposal before C++17 is
settled, anyway, I'd like to make this work public now.
Please let me know if anyone wants to be a champion if it's submitted.
Thanks
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e2d5660e-2cf7-4107-868d-7027bdce344f%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e2d5660e-2cf7-4107-868d-7027bdce344f%40isocpp.org?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3DZjfOq_rvNQPB-qWrNLhaLMs-1fG4-11q%2BpXTYqCPQ2w%40mail.gmail.com.
p***@gmail.com
2016-04-13 22:33:43 UTC
Permalink
Post by Richard Smith
Post by TONGARI J
Hi,
http://jamboree.github.io/designator-draft.html
https://github.com/jamboree/clang/tree/feature/designator
Have you considered the interaction of this proposal with forwarding
functions and with types like std::function? I would find it problematic if
correct forwarding is not possible for functions with designated
parameters. I think you will encounter resistance if something like this is
void f(int .foo, int .bar);
std::function<void(int .foo, int .bar)> fn = f;
fn(.bar = 1, .foo = 2);
(a) designated parameter names to become part of a function type, and
What are the downsides of disignated parameters being part of a function
type?
Post by Richard Smith
(b) add a way to write a function template that accepts a pack of
designated parameters, capturing both the names and the values, and
allowing both to be used when forwarding
Wouldn't this require some kind of reflection mechanism? (To save the
names).
Post by Richard Smith
But (b) in particular seems like it would add a lot of complexity. I hope
there's a better alternative.
Post by TONGARI J
I'm not sure if it's proper to submit a new proposal before C++17 is
settled, anyway, I'd like to make this work public now.
Please let me know if anyone wants to be a champion if it's submitted.
Thanks
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e2d5660e-2cf7-4107-868d-7027bdce344f%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e2d5660e-2cf7-4107-868d-7027bdce344f%40isocpp.org?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/84335887-a9d3-4ef1-97eb-921220b1fb0e%40isocpp.org.
Richard Smith
2016-04-14 00:48:27 UTC
Permalink
Post by p***@gmail.com
Post by Richard Smith
Post by TONGARI J
Hi,
http://jamboree.github.io/designator-draft.html
https://github.com/jamboree/clang/tree/feature/designator
Have you considered the interaction of this proposal with forwarding
functions and with types like std::function? I would find it problematic if
correct forwarding is not possible for functions with designated
parameters. I think you will encounter resistance if something like this is
void f(int .foo, int .bar);
std::function<void(int .foo, int .bar)> fn = f;
fn(.bar = 1, .foo = 2);
(a) designated parameter names to become part of a function type, and
What are the downsides of disignated parameters being part of a function
type?
I think increased complexity is the big one. Presumably we'd want this to
work:

void f(int .a, int .b);
void (*p)(int, int) = &f;

... which implies there is a conversion that discards the names from the
type. Adding names should presumably also be permissible (perhaps with an
explicit cast), as should calling through a function pointer whose
parameter names differ from those of the function.

It also means that everyone who is decomposing a function type via a
template needs to change their code to cope with designators. The way that
Post by p***@gmail.com
(b) add a way to write a function template that accepts a pack of
Post by Richard Smith
designated parameters, capturing both the names and the values, and
allowing both to be used when forwarding
Wouldn't this require some kind of reflection mechanism? (To save the
names).
"Reflection" is not a well-defined term; we can't say what is or isn't a
reflection mechanism. But I don't see this as being much different from
template argument deduction deducing the types of parameters from the type
of arguments (is that reflection? opinions vary).

We could imagine something like this:

template<typename F, designator ...D, typename ...T> decltype(auto) f(F f,
T &&... .D) {
return f(0, .D = std::forward<T>(D) ...);
}

That is: a new kind of template parameter representing a designator, and
designator names are looked up to see if they name such a parameter before
assuming they're an opaque identifier. (Plus a notional "empty designator"
that is deduced in cases where no designator is specified.) I don't think I
like this approach, and as noted, I hope there's a better answer.
Post by p***@gmail.com
But (b) in particular seems like it would add a lot of complexity. I hope
Post by Richard Smith
there's a better alternative.
Post by TONGARI J
I'm not sure if it's proper to submit a new proposal before C++17 is
settled, anyway, I'd like to make this work public now.
Please let me know if anyone wants to be a champion if it's submitted.
Thanks
--
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e2d5660e-2cf7-4107-868d-7027bdce344f%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e2d5660e-2cf7-4107-868d-7027bdce344f%40isocpp.org?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/84335887-a9d3-4ef1-97eb-921220b1fb0e%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/84335887-a9d3-4ef1-97eb-921220b1fb0e%40isocpp.org?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqns6dE7nro%3D3btO9Wy0n%3Dx2ev8MELGs8XB2m9PRTMsEqA%40mail.gmail.com.
Jens Maurer
2016-04-14 13:02:58 UTC
Permalink
Post by Richard Smith
void f(int .a, int .b);
void (*p)(int, int) = &f;
... which implies there is a conversion that discards the names from the type. Adding names should presumably also be permissible (perhaps with an explicit cast), as should calling through a function pointer whose parameter names differ from those of the function.
Note that I've already done some work for function pointer conversions (4.12)
when I introduced "noexcept" to the type system. That doesn't mean it's
easy, but the locations that need changes are at least text-searchable.
Post by Richard Smith
That is: a new kind of template parameter representing a designator,
and designator names are looked up to see if they name such a
parameter before assuming they're an opaque identifier. (Plus a
notional "empty designator" that is deduced in cases where no
designator is specified.) I don't think I like this approach, and as
noted, I hope there's a better answer.
Agreed, in particular with the last sentence.

Jens
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/570F9502.5080607%40gmx.net.
g***@gmail.com
2016-04-14 01:36:06 UTC
Permalink
Post by TONGARI J
Hi,
http://jamboree.github.io/designator-draft.html
https://github.com/jamboree/clang/tree/feature/designator
I'm not sure if it's proper to submit a new proposal before C++17 is
settled, anyway, I'd like to make this work public now.
Please let me know if anyone wants to be a champion if it's submitted.
Thanks
This looks like a very well written and presented proposal. I think it
could be better evaluated though if there were more discussion about it in
the context of existing API designs that have been created with languages
that already have the features the proposed. In particular regarding named
function parameters.

My own experience of using libraries with extensive numbers of
parameters are the Microsoft COM object libraries that lay behind
applications like Microsoft Word and Excel etc.
See here:
https://msdn.microsoft.com/en-us/library/kw65a0we.aspx
https://msdn.microsoft.com/en-us/library/office/ff194068.aspx

This proposal would seem to make using such libraries a lot easier?

As important to me though is whether people consider such API designs good?
And do we want to encourage more of them by making them easier?

So to my mind we have to evaluate this proposal against real existing
APIs while also determining if those real API's need to be as complex as
they are so we. This should help us verify if this proposal helps with
using such API's and reveal whether an alternative API design or language
feature would be better to get the kinds of api's we do want.

I don't feel I can appreciate the value of this proposal without such
discussion

If more recent API's could be discussed it might even more relevant. I am
thinking some of the web driving api's (think setting html attributes from
code etc). like those in the ASP.NET's MVC API, which are C#
API's. Maybe that could be addressed? Perhaps a lot of
lessons/encouragement could be learned from that?

So I think ultimately we have to compare this proposal against these types
of API's and evaluate the alternatives to appreciate this proposal, don't
we?

Thanks for the proposal so far.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2623effe-c614-4956-964d-2b5028f5d57e%40isocpp.org.
Bryce Glover
2016-04-14 21:19:23 UTC
Permalink

I have indeed toyed with the idea of writing a rumination paper on why named arguments have failed, as far as I know and have observed it (which doesn’t cover all the old proposals), but perhaps I was kinda hoping I wouldn’t need to. :)
⋮
As a lurker who’s been following some of the more recent discussions on adding named arguments to C++, I would actually appreciate seeing a more expansive paper that does go back and, as you put it, ‘cover all the old arguments’ in addition to your more concise summary of more contemporary events in this area. Given your reluctance to do that right now, though, I wouldn’t mind seeing the more extensive analysis as either part of a later revision of your paper or a separate one altogether.

— Bryce Glover
  ***@gmail.com
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/FE05C500-82B4-4507-9008-71179053ECE3%40gmail.com.
Bryce Glover
2016-04-14 21:27:20 UTC
Permalink
⋮
This looks like a very well written and presented proposal. I think it could be better evaluated though if there were more discussion about it in the context of existing API designs that have been created with languages that already have the features the proposed. In particular regarding named function parameters.
My own experience of using libraries with extensive numbers of parameters are the Microsoft COM object libraries that lay behind applications like Microsoft Word and Excel etc.
https://msdn.microsoft.com/en-us/library/kw65a0we.aspx <https://msdn.microsoft.com/en-us/library/kw65a0we.aspx>
https://msdn.microsoft.com/en-us/library/office/ff194068.aspx <https://msdn.microsoft.com/en-us/library/office/ff194068.aspx>
This proposal would seem to make using such libraries a lot easier?
As important to me though is whether people consider such API designs good? And do we want to encourage more of them by making them easier?
So to my mind we have to evaluate this proposal against real existing APIs while also determining if those real API's need to be as complex as they are so we. This should help us verify if this proposal helps with using such API's and reveal whether an alternative API design or language feature would be better to get the kinds of api's we do want.
I don't feel I can appreciate the value of this proposal without such discussion
If more recent API's could be discussed it might even more relevant. I am thinking some of the web driving api's (think setting html attributes from code etc). like those in the ASP.NET <http://asp.net/>'s MVC API, which are C# API's. Maybe that could be addressed? Perhaps a lot of lessons/encouragement could be learned from that?
So I think ultimately we have to compare this proposal against these types of API’s and evaluate the alternatives to appreciate this proposal, don't we?
Thanks for the proposal so far.
Off the top of my head, another set of examples that might bear examination could exist in Apple’s Cocoa library for Objective-C, which, IIRC, heavily utilizes that language’s support for named arguments.

— Bryce Glover
  ***@gmail.com
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/57F50182-39F9-4CD9-8781-48BF1294EF28%40gmail.com.
Andrew Tomazos
2016-04-15 03:36:57 UTC
Permalink
Hi Tongari,

I've actually been working on a designated initialization proposal. My
current thinking on the matter was to propose an uncontroversial first step
of motivating and adopting in C++ a strict subset of the existing C feature
(just the parts that clearly make sense for C++), and then showing how this
fits into a large family of possible future roadmaps, such as the one you
outline in your proposal.

My reaction to reading your proposal is that you are being too ambitious.
It would be multiple years of work to get standardized such a large feature
of "uniform designators" across function calls, aggregate initialization
and other types of initialization - and that is assuming consensus can be
achieved at all, which given the history of named parameter proposals, is a
long shot.

That's why I think breaking off and nailing down a smaller first step would
be more practical. The C feature has extensive existing practice that can
be appealed to, so I think a subset-only proposal has a much better chance
of getting through. Once that gets in and is nailed down, a proposal to
extend an existing feature will be much better received than trying to do
everything at once.

Regards,
Andrew.
Post by TONGARI J
Hi,
http://jamboree.github.io/designator-draft.html
https://github.com/jamboree/clang/tree/feature/designator
I'm not sure if it's proper to submit a new proposal before C++17 is
settled, anyway, I'd like to make this work public now.
Please let me know if anyone wants to be a champion if it's submitted.
Thanks
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e2d5660e-2cf7-4107-868d-7027bdce344f%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e2d5660e-2cf7-4107-868d-7027bdce344f%40isocpp.org?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KH%2BwQxcNWsadfxqtM1nMopQ28vnJ0wmG%2B_WUzth8fiSN2g%40mail.gmail.com.
TONGARI J
2016-04-15 03:56:53 UTC
Permalink
Hi Andrew,
Post by Andrew Tomazos
Hi Tongari,
I've actually been working on a designated initialization proposal. My
current thinking on the matter was to propose an uncontroversial first step
of motivating and adopting in C++ a strict subset of the existing C feature
(just the parts that clearly make sense for C++), and then showing how this
fits into a large family of possible future roadmaps, such as the one you
outline in your proposal.
My reaction to reading your proposal is that you are being too ambitious.
It would be multiple years of work to get standardized such a large feature
of "uniform designators" across function calls, aggregate initialization
and other types of initialization - and that is assuming consensus can be
achieved at all, which given the history of named parameter proposals, is a
long shot.
Obviously, Richard is much more ambitious than me ;)
What I proposed is really the minimal, simplest model in practice.
Post by Andrew Tomazos
That's why I think breaking off and nailing down a smaller first step
would be more practical. The C feature has extensive existing practice
that can be appealed to, so I think a subset-only proposal has a much
better chance of getting through. Once that gets in and is nailed down, a
proposal to extend an existing feature will be much better received than
trying to do everything at once.
I'm not sure if you're an advocator of the alternative described in section
5.7 <http://57-alternative-of-designated-arguments>, which I already showed
would be a dead end for C++, or you just want to cutoff the proposal to an
even smaller subset.
Anyway, Richard seems to have the exact opposite opinion that we should
Post by Andrew Tomazos
we don't get there by minimizing the amount of change to the language or
specification, we get there by making the changes complete so they feel
like an extension of what came before.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8177d926-1afe-4ca9-a2b3-a120532d9bbe%40isocpp.org.
Andrew Tomazos
2016-04-15 04:46:00 UTC
Permalink
Post by TONGARI J
Hi Andrew,
Post by Andrew Tomazos
Hi Tongari,
I've actually been working on a designated initialization proposal. My
current thinking on the matter was to propose an uncontroversial first step
of motivating and adopting in C++ a strict subset of the existing C feature
(just the parts that clearly make sense for C++), and then showing how this
fits into a large family of possible future roadmaps, such as the one you
outline in your proposal.
My reaction to reading your proposal is that you are being too
ambitious. It would be multiple years of work to get standardized such a
large feature of "uniform designators" across function calls, aggregate
initialization and other types of initialization - and that is assuming
consensus can be achieved at all, which given the history of named
parameter proposals, is a long shot.
Obviously, Richard is much more ambitious than me ;)
What I proposed is really the minimal, simplest model in practice.
Post by Andrew Tomazos
That's why I think breaking off and nailing down a smaller first step
would be more practical. The C feature has extensive existing practice
that can be appealed to, so I think a subset-only proposal has a much
better chance of getting through. Once that gets in and is nailed down, a
proposal to extend an existing feature will be much better received than
trying to do everything at once.
I'm not sure if you're an advocator of the alternative described in section
5.7 <http://57-alternative-of-designated-arguments>, which I already
showed would be a dead end for C++, or you just want to cutoff the proposal
to an even smaller subset.
An even smaller subset. Consider it as the intersection of your proposal
and the existing C feature. This would necessarily be forward compatible
with your proposal, as the intersection is a subset of your proposal. The
people that support your proposal must also support such a step.
Additionally, there may be people that don't support your proposal in
entirety, but support such a step. Therefore that step has a better chance
of achieving consensus than your proposal.

Anyway, Richard seems to have the exact opposite opinion that we should
Post by TONGARI J
Post by Andrew Tomazos
we don't get there by minimizing the amount of change to the language or
specification, we get there by making the changes complete so they feel
like an extension of what came before.
I think Richard and I are talking about different things. He is talking
about the design. I am talking about the execution.

I'm just suggesting we should break up the proposal into a series of steps,
not suggesting we change the destination.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHLBHmdp4XpyHKxrjfZM8HUXAG9jWp9dpk33rTYsmPrWoQ%40mail.gmail.com.
TONGARI J
2016-04-15 06:41:47 UTC
Permalink
Post by Andrew Tomazos
Post by TONGARI J
Hi Andrew,
Post by Andrew Tomazos
Hi Tongari,
I've actually been working on a designated initialization proposal. My
current thinking on the matter was to propose an uncontroversial first step
of motivating and adopting in C++ a strict subset of the existing C feature
(just the parts that clearly make sense for C++), and then showing how this
fits into a large family of possible future roadmaps, such as the one you
outline in your proposal.
My reaction to reading your proposal is that you are being too
ambitious. It would be multiple years of work to get standardized such a
large feature of "uniform designators" across function calls, aggregate
initialization and other types of initialization - and that is assuming
consensus can be achieved at all, which given the history of named
parameter proposals, is a long shot.
Obviously, Richard is much more ambitious than me ;)
What I proposed is really the minimal, simplest model in practice.
Post by Andrew Tomazos
That's why I think breaking off and nailing down a smaller first step
would be more practical. The C feature has extensive existing practice
that can be appealed to, so I think a subset-only proposal has a much
better chance of getting through. Once that gets in and is nailed down, a
proposal to extend an existing feature will be much better received than
trying to do everything at once.
I'm not sure if you're an advocator of the alternative described in section
5.7 <http://57-alternative-of-designated-arguments>, which I already
showed would be a dead end for C++, or you just want to cutoff the proposal
to an even smaller subset.
An even smaller subset. Consider it as the intersection of your proposal
and the existing C feature. This would necessarily be forward compatible
with your proposal, as the intersection is a subset of your proposal. The
people that support your proposal must also support such a step.
Additionally, there may be people that don't support your proposal in
entirety, but support such a step. Therefore that step has a better chance
of achieving consensus than your proposal.
Well, it'd be fine if you could push designated initializers into C++17,
and I can aim for C++20. But if designated initializers could only aim for
C++20, another 3 years seem to be a long time for designated
arguments...during the long period, people could have established the
boring tricks to emulate designated arguments and it's not hard to imagine
that they're ask for the syntax-sugar alternative I illustrated instead of
a formal approach.

Maybe I'm just too pessimistic...
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANCwVhfa32N%3DcQVur_QY1wmFbPMNxVYErKPsLAYQWZ9yEC%3DQGg%40mail.gmail.com.
Andrew Tomazos
2016-04-15 17:04:13 UTC
Permalink
Post by TONGARI J
Post by Andrew Tomazos
Post by TONGARI J
Hi Andrew,
Post by Andrew Tomazos
Hi Tongari,
I've actually been working on a designated initialization proposal. My
current thinking on the matter was to propose an uncontroversial first step
of motivating and adopting in C++ a strict subset of the existing C feature
(just the parts that clearly make sense for C++), and then showing how this
fits into a large family of possible future roadmaps, such as the one you
outline in your proposal.
My reaction to reading your proposal is that you are being too
ambitious. It would be multiple years of work to get standardized such a
large feature of "uniform designators" across function calls, aggregate
initialization and other types of initialization - and that is assuming
consensus can be achieved at all, which given the history of named
parameter proposals, is a long shot.
Obviously, Richard is much more ambitious than me ;)
What I proposed is really the minimal, simplest model in practice.
Post by Andrew Tomazos
That's why I think breaking off and nailing down a smaller first step
would be more practical. The C feature has extensive existing practice
that can be appealed to, so I think a subset-only proposal has a much
better chance of getting through. Once that gets in and is nailed down, a
proposal to extend an existing feature will be much better received than
trying to do everything at once.
I'm not sure if you're an advocator of the alternative described in section
5.7 <http://57-alternative-of-designated-arguments>, which I already
showed would be a dead end for C++, or you just want to cutoff the proposal
to an even smaller subset.
An even smaller subset. Consider it as the intersection of your proposal
and the existing C feature. This would necessarily be forward compatible
with your proposal, as the intersection is a subset of your proposal. The
people that support your proposal must also support such a step.
Additionally, there may be people that don't support your proposal in
entirety, but support such a step. Therefore that step has a better chance
of achieving consensus than your proposal.
Well, it'd be fine if you could push designated initializers into C++17,
and I can aim for C++20. But if designated initializers could only aim for
C++20, another 3 years seem to be a long time for designated
arguments...during the long period, people could have established the
boring tricks to emulate designated arguments and it's not hard to imagine
that they're ask for the syntax-sugar alternative I illustrated instead of
a formal approach.
Maybe I'm just too pessimistic...
I think it's already too late to put new work into C++17.

As proposals are approved they are applied to the working draft. Multiple
proposals that build upon one another can be applied to the working draft
between a single release cycle of the IS.

Having said that, I think C++20 is too ambitious a target for your entire
proposal. I consider it about twice as large as defaulted comparisons.

Default comparisons were at the stage of your proposal in late 2013 by Oleg
Smolsky (informal paper, prototype impl):


https://groups.google.com/a/isocpp.org/d/topic/std-proposals/La6AbyApdTc/discussion

and it's not clear yet whether they will just squeak into C++17.

I don't think there is much risk of people getting a "syntax-sugar
alternative" instead of a "formal approach". All alternative approaches
will be discussed and considered ad nauseam for many years before selecting
and standardizing one or none.

As long as whatever the first step proposal is, is shown to be forward
compatible with all the feasible approaches we might want to select later,
I think it can achieve consensus, and C++20 is a realistic target.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHLffno6Wc%2BRCRMYrdWXkrt9BMa7aPKn84z%2BQ8KSEx99rw%40mail.gmail.com.
TONGARI J
2016-04-15 17:34:32 UTC
Permalink
Post by Andrew Tomazos
I think it's already too late to put new work into C++17.
As proposals are approved they are applied to the working draft. Multiple
proposals that build upon one another can be applied to the working draft
between a single release cycle of the IS.
Having said that, I think C++20 is too ambitious a target for your entire
proposal. I consider it about twice as large as defaulted comparisons.
Default comparisons were at the stage of your proposal in late 2013 by
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/La6AbyApdTc/discussion
and it's not clear yet whether they will just squeak into C++17.
I don't think there is much risk of people getting a "syntax-sugar
alternative" instead of a "formal approach". All alternative approaches
will be discussed and considered ad nauseam for many years before selecting
and standardizing one or none.
As long as whatever the first step proposal is, is shown to be forward
compatible with all the feasible approaches we might want to select later,
I think it can achieve consensus, and C++20 is a realistic target.
Fine, then please c.c. me if you have a draft to review or anything happens
to your proposal so I can continue the work.
You could also mention some future direction as the idea I illustrated in
my proposal, if that helps.

Good luck!
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANCwVheXPBkzd0MuD9Q9-OXSA4%3D5Ws_nuTXPjhQcPzXOjdXcRg%40mail.gmail.com.
Loading...