Re: Designated Initializer List Status

[Bryce Glover]

On Nov 21, 2015, at 3:12 PM, std-pr...@isocpp.org wrote:

std-pr...@isocpp.org

Google Groups

Topic digest
View all topics

• Designated initializer list status? - 9 Updates

(snipped…)

Designated initializer list status?

(snipped)

Nicol Bolas <jmck...@gmail.com>: Nov 21 09:56AM -0800 (snipped) ⋮ I would also suggest that any such proposal not have "improve parity with C" as its primary motivation (or in the case of the above, *only* motivation). More convincing motivations should revolve around using it in C++ code. What can you do with it that you can't do without it. The fact that it's in C is a good way to prove that the idea works, but that alone is hardly sufficient motivation for a C++ feature.   For example, there was a discussion awhile back about named parameters <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/3iegpTsMuT0/hgmDlYkWIgAJ>. It lead to the revelation that, if you have designated initializers, you can more or less get that. The function would take a single struct type, and you would call it with `funcName({.param1 = X, .param2 = Y, etc})`. Naturally, they wanted to add language functionality to remove the parens, but that's unnecessary. The main point is to give people an easy way to pass named parameters to a function, and designated initializers would allow precisely that.   ⋮ (snipped)

⋮ (snipped)

Back to top

You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to std-proposal...@isocpp.org.

     Even though I’m only speaking about this from an end-user perspective, I agree with the points that Nicol Bolas made in the part of that e-mail of his which I quoted above.  In particular, I agree that a formal proposal to add C99’s designated initializers into C++(17?) should dress the concerns that he raised in the first paragraph I quoted.  One of the examples that this paper could use to indicate possible use cases could indeed be the one that he referenced in his second paragraph, but the proposal’s author might also want to mention that, if I understand and remember correctly, there is already a workaround for this in the form of method chaining.  That technique, however, seems to be a bit of kludge to me, especially since it takes an entity emitted from an initial function call and performs one or more transformations on it using more functions when a programmer may really have intended to pass multiple arguments to a single function, thus avoiding the expenses involved in setting up and tearing down multiple stack frames.  

— Bryce Glover

　 Random...@gmail.com

[Bryce Glover]

     Whoops, I gave my e-mail the wrong subject, thereby separating it from its intended target thread!  Let’s try that again, shall we?  

— Bryce Glover

　 Random...@gmail.com

[Patrice Roy]

The nice thing about method chaining is that it does not force maintenance of specific names that were not previously part of the type and function interfaces (apart from documentation purposes). This proposal seems to me to be imposing an unneeded burden on interfaces, and there are indeed many workarounds.

Named arguments are less annoying in C where things such as encapsulation are not as big a concern. I understand better why they allow it there.

I'd have to see a very convincing argument to go for this proposal, to be honest, given the downsides.

--

---
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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

[Nicol Bolas]

On Monday, November 23, 2015 at 8:30:43 PM UTC-5, Patrice Roy wrote:

The nice thing about method chaining is that it does not force maintenance of specific names that were not previously part of the type and function interfaces (apart from documentation purposes). This proposal seems to me to be imposing an unneeded burden on interfaces, and there are indeed many workarounds.

Named arguments are less annoying in C where things such as encapsulation are not as big a concern. I understand better why they allow it there.

I'd have to see a very convincing argument to go for this proposal, to be honest, given the downsides.

We're not talking about "named arguments". We're talking about designated initializers, which could be used to give the effects of named arguments, but are useful for more than just that.

[Patrice Roy]

I understand the usefulness and the distinction, but the point stands: so far, the interface downsides seem to weigh much more than the syntactic advantages. As many have said, usefulness is not sufficient, particularly if the feature has strong pain points.

--

[Nicol Bolas]

On Tuesday, November 24, 2015 at 11:52:36 AM UTC-5, Patrice Roy wrote:

I understand the usefulness and the distinction, but the point stands: so far, the interface downsides seem to weigh much more than the syntactic advantages. As many have said, usefulness is not sufficient, particularly if the feature has strong pain points.

Interface downsides of what? There is no interface. Remember: the idea is for designated initializers, not named arguments. The latter is merely a potential application of the former.

[Patrice Roy]

Maybe I'm misunderstanding your point. Tell me where I'm wrong:

• In a simple aggregate with public data members, designated initializers would let us initialize data members through their names, which is not a problem as the names are part on the interface. This is not a problem for me
• In a class with private data members and its ctors, or with a function signature in general, designated initializers would let us use the arguments by name, circumventing the link between the order of arguments on the caller's side and on the callee's side. This is not necessarily a bad thing, except that it binds the names in the caller code to the names in the callee's signature. This name binding is a serious bother in my view; I do not see this «addition» to the callee's interface as a positive feature (to say the least)

If I'm misunderstanding the proposal on this last point, then I might have missed how the link between the names used in client code and in the called functions is made (it's quite possible). Unless I'm mistaken, there will need to be a by-name link somewhere, which seems to me like a maintenance problem anywhere but where those names were already public and documented as such in the first place.

Cheers!

--

[Sean Middleditch]

On Tuesday, November 24, 2015 at 9:21:30 AM UTC-8, Patrice Roy wrote:

Maybe I'm misunderstanding your point. Tell me where I'm wrong:

• In a simple aggregate with public data members, designated initializers would let us initialize data members through their names, which is not a problem as the names are part on the interface. This is not a problem for me
• In a class with private data members and its ctors, or with a function signature in general, designated initializers would let us use the arguments by name, circumventing the link between the order of arguments on the caller's side and on the callee's side. This is not necessarily a bad thing, except that it binds the names in the caller code to the names in the callee's signature. This name binding is a serious bother in my view; I do not see this «addition» to the callee's interface as a positive feature (to say the least)

If I'm misunderstanding the proposal on this last point, then I might have missed how the link between the names used in client code and in the called functions is made (it's quite possible). Unless I'm mistaken, there will need to be a by-name link somewhere, which seems to me like a maintenance problem anywhere but where those names were already public and documented as such in the first place.

He isn't proposing anything that needs that. He doesn't want to support constructors and wants only designated initialization of aggregates (i.e. simple structs, maybe with base class support tossed in).

I, not he, argued that this non-holistic design is the wrong approach for C++ and that constructors must be considered for this feature to be worth taking to and through the committee.

Yes, any serious proposal that does involve function parameter names would most absolutely have to provide a way to opt-in to having the names become part of the API, with the default for them to not. This opt-in would either be at the function declaration via some new [use of a] [contextual] keyword or sigil or even be per-parameter.

My original treatise of the subject some ~6-12 months ago started out with a position identical (or very similar) to Jason's: get aggregate designated initializers through the committee first by themselves, then see about extending that to constructors as a second proposal, then the coup de grace of named parameters. My opinion on the matter has evolved since then. 

[Patrice Roy]

Thanks for the precisions. Cheers!