220 11475 <0bf9fa1c-db92-4f3c-bb2f-627e8b4e6135@isocpp.org> article Path: news.gmane.org!not-for-mail From: Matthew Fioravante Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Named function parameters using anonymous structs for C and C++ Date: Tue, 17 Jun 2014 07:59:09 -0700 (PDT) Lines: 86 Approved: news@gmane.org Message-ID: <0bf9fa1c-db92-4f3c-bb2f-627e8b4e6135@isocpp.org> References: <72c49240-547b-4bf6-8b27-aff6a61c1272@isocpp.org> <36D3B24B-7F24-4ED5-A27C-F4EF71CF244C@gmail.com> <29C6D83B-BD31-42A9-B7BD-2C797E3FE58C@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2759_8892083.1403017149445" X-Trace: ger.gmane.org 1403017159 23556 80.91.229.3 (17 Jun 2014 14:59:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Jun 2014 14:59:19 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDELF54RTIGRBPVPQGOQKGQERT264AI@isocpp.org Tue Jun 17 16:59:12 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qc0-f197.google.com ([209.85.216.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Wwuqt-0007lV-DP for gclcip-std-proposals@m.gmane.org; Tue, 17 Jun 2014 16:59:11 +0200 Original-Received: by mail-qc0-f197.google.com with SMTP id i8sf26221383qcq.0 for ; Tue, 17 Jun 2014 07:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=nsGoCh9dTuW/MV6AvmB8c3a7C3WOgsEoNn8CE2ZGRq4=; b=xQpsruKJpvkzGe49pWr0c3cwGKONNvxmAjYCOG3eS+M3xEZ4le9v3aX4vv0Acbf37O 6HVq57R3vfRIenrPJRmW2qJ0i5lfo5r3wlrnNW7h+X2/PZVxujntM/vZ55tDAY03tYue ZSdcV28cZgp3eb9xQl5GUVDeUkVNt/vq5aiH7JvX4ONvfjHWQIUEhSL4UgcUFwZGnAUG +A6tLcYRP+GFtq2rs7dcNM0jad4SKUG7EjepGmvqCSgvGPQAADUjXwJI36jSPB46Si2V Gz3LAxvYgseFnahesn/38U3DMcrUQyAzBEXAZb529XV89TAe3hhteaqm/BA82n+03V8M NbAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=nsGoCh9dTuW/MV6AvmB8c3a7C3WOgsEoNn8CE2ZGRq4=; b=lTFR+UXu1YD0i+mlBMEj53oT/Q0sLWVFHDlVZtMveos+HaNBCNfSkDpy/FYU8b4nG8 46ypwzQIxFJnGUcjtTfiz4ieEJ8spuDKDMLANKxwbiOXWegSxnzk136mWDi3IbYpOSQG vCoNYGtqno5l+jG/ymV0JSF5O7QidjIfwg6Y/ZGiC/URZkp6RamTRt0Sn4JFOt090ciN lB/0PeOrDgnyyLytLAg1BWMCB4mpbDe+G608sGUfQc7p+a5VUjhcX8eGe0oLyf4k1qdQ 2cO36G2z+Chhx7asYrl/Icnmnd9h7DWjNXAjg7aqdI1NyOkEk5VQJb6x3NggvlFQZiqM AwWQ== X-Gm-Message-State: ALoCoQmZxB/RFEerJMmK8JVyj7y9lAg7aIHx2NpFnbao1CfjyqElPO4ZyPkuCTtb9TFte7Uz6fKy X-Received: by 10.58.225.225 with SMTP id rn1mr770364vec.5.1403017150607; Tue, 17 Jun 2014 07:59:10 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.41.243 with SMTP id z106ls2494832qgz.54.gmail; Tue, 17 Jun 2014 07:59:10 -0700 (PDT) X-Received: by 10.140.108.162 with SMTP id j31mr43714qgf.18.1403017150006; Tue, 17 Jun 2014 07:59:10 -0700 (PDT) In-Reply-To: X-Original-Sender: fmatthew5876@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:11475 Archived-At: ------=_Part_2759_8892083.1403017149445 Content-Type: text/plain; charset=UTF-8 As I'm working on the paper and thinking about the details of the proposal, I've found a few issues to wrestle with. The major difference between aggregate initialization and a set of what I call in the paper compiler generated "aggregate member constructors": Aggregates can be left in an uninitialized state by not specifying an initializer. If we drop aggregate initialization in favor of constructors, we still need to support this behavior. Named function parameters using structs chicken and egg problem: If we had named function params, aka: int foo(int a, int b, int c); foo(.a = 1, .b = 2, .c = 4); Then having designated initializers for structs would just fall out from this in the constructors. If we introduce designated initializers first, then named function parameters are derived from that. I'm falling more and more into the second camp because as I think about it, separating positional and named arguments seems to make a lot of sense. The names of the positional arguments stay out of the source level API. If we go with the first approach, all of the sudden the function names everyone is using in legacy code become source level API. This is not something I'd want to wrestle with in a large legacy code base. Instead, we can control our interfaces more explicitly. -- --- 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+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_2759_8892083.1403017149445 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As I'm working on the paper and thinking about the details= of the proposal, I've found a few issues to wrestle with.

The major= difference between aggregate initialization and a set of what I call in th= e paper compiler generated "aggregate member constructors":

Aggregat= es can be left in an uninitialized state by not specifying an initializer. = If we drop aggregate initialization in favor of constructors, we still need= to support this behavior.


Named function parameters using struc= ts chicken and egg problem:

If we had named function params, aka:
int foo(int a, int b, int c);
foo(.a =3D 1, .b =3D 2, .c =3D 4);
Then having designated initializers for structs would just fall out fr= om this in the constructors.

If we introduce designated initializers= first, then named function parameters are derived from that. I'm falling m= ore and more into the second camp because as I think about it, separating p= ositional and named arguments seems to make a lot of sense.

The nam= es of the positional arguments stay out of the source level API. If we go w= ith the first approach, all of the sudden the function names everyone is us= ing in legacy code become source level API. This is not something I'd want = to wrestle with in a large legacy code base. Instead, we can control our in= terfaces more explicitly.


--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_2759_8892083.1403017149445-- .