220 22854 article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Designated initializer list status? Date: Mon, 23 Nov 2015 12:34:27 -0800 (PST) Lines: 134 Approved: news@gmane.org Message-ID: References: <8b5cda67-8c22-41b6-b99d-ac2ab22f30d2@isocpp.org> <8be0613a-76d8-425c-8eab-5930a2cf2549@isocpp.org> <1857411a-a254-45d6-b9c4-ce91b8f16858@isocpp.org> <221729a6-7d3d-490a-8ab2-43da5d0f277a@isocpp.org> <63c58fcf-ec0e-4be9-b497-47c3a19b9027@isocpp.org> <91745fb2-3e6a-42d8-9021-90606ecfddad@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5503_495297068.1448310867924" X-Trace: ger.gmane.org 1448310890 4238 80.91.229.3 (23 Nov 2015 20:34:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Nov 2015 20:34:50 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBVHQZWZAKGQEVHTY2XA@isocpp.org Mon Nov 23 21:34:35 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f72.google.com ([209.85.218.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a0xoi-0000mD-TL for gclcip-std-proposals@m.gmane.org; Mon, 23 Nov 2015 21:34:29 +0100 Original-Received: by oiww189 with SMTP id w189sf351867459oiw.2 for ; Mon, 23 Nov 2015 12:34:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=xCbLYi+q7Kbpl2DbIbhQdvzK55/GoOEeEZ36fDCoonM=; b=KK8+yqnZUs0ExwgDkR26oqYh1w13RoZdBAzgnePLyof2cy/9eG+oWHsl/KWZ6N2e+A WRyrMmd/MyDmpJtMn7oSbBxTv4EIOMjMTGoOXvHiM0u7Z8Cf9R0hhheMiuN52R8iQerS ZCo7XlpJNV6hwkCuK7wYYA3zIecydWL2BBfobOT7ZhPoSqcI3Z0vXjGRyPm1ec8UkCce MAvcA/M40sHFfDcrSVR/N8IPvwh+XbWXnsHnOhpkccxtqF1eGvrwS/2VhoujIOLc9wa9 elqhhzUBsnF/iItjVkKCfzwt88hXH90flt+xeWYrea4oRJHIV/WF8lM3aWr++hK/pXI8 LuzQ== 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 :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=xCbLYi+q7Kbpl2DbIbhQdvzK55/GoOEeEZ36fDCoonM=; b=dhQf9Fo5G/fKWf1h9SXakRdlUO8zxWp92xQs8gNJWy2NdLLHzBjpHVhyyZ4MxlCmtT qhK1QErTgRdoJ5iGuD7+bFutHMLTnP7ELaHHIAj11twLiHuMMd4/gEBQPb7saKxJ7u0t BCHi+EeSXbjB7rFiBQNxe3pu3xGIkV1GK/zrj1AkyjtooJax4Jizo7JItbW5AO5LnfpO SyHExwMsTP7tDduMgF236XXmHPu+PaIST56Nrq8mAnpei77pskQyseT0+4BGQGs6h8x/ Mp7ZeMW0BBgwC2BOjH17SGkFNoPnTpOCDloWnCd9ZhiP5sB6sM4m6m0lUfK0JzhKmq70 3x4g== 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:content-type:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=xCbLYi+q7Kbpl2DbIbhQdvzK55/GoOEeEZ36fDCoonM=; b=c2Qm1CsuQJcVzZPXVqenJFIYebq/33BUnJgK6UI3IGa9R6vr/9mBFYVbVVwmio3Pk3 M/A5cQg23dgnuU9qMYoqqZCDiy6saRYoC82HDh2kb0GeWC4qKEBHJ6V4B0l4jckiYNyC U0rMJ/TqLJEKFKlVzFz79a6BvTMhQyA3M8PgcIPGykibScc889D20/nMwZq7EOEuQ+ea 9gG9gg+MHIZVX6bfd+oE4R6UE7GGzgfmz1e9CoqVpPlu57wDMwK0G4YzLV3BxUMDeGqK b04BE3ldKysE0ZSRD5Ca7kLTFIj7/elkaBr9OZ+6V5rTYcjZBRDAzzXnZSu14IgaJA7N nqrA== X-Gm-Message-State: ALoCoQn6TCFECGR5w7TTKQ5Bjc7w9TXRRYdL8RTJkF3UFbl9uwFq16AXCysNSM27UAChRKv4LMyZ X-Received: by 10.182.99.225 with SMTP id et1mr26758066obb.36.1448310869301; Mon, 23 Nov 2015 12:34:29 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.159.6 with SMTP id wy6ls649377igb.10.gmail; Mon, 23 Nov 2015 12:34:28 -0800 (PST) X-Received: by 10.50.93.37 with SMTP id cr5mr365537igb.1.1448310868566; Mon, 23 Nov 2015 12:34:28 -0800 (PST) In-Reply-To: X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:22854 Archived-At: ------=_Part_5503_495297068.1448310867924 Content-Type: multipart/alternative; boundary="----=_Part_5504_1937590043.1448310867924" ------=_Part_5504_1937590043.1448310867924 Content-Type: text/plain; charset=UTF-8 On Monday, November 23, 2015 at 2:17:27 PM UTC-5, Ville Voutilainen wrote: > > On 23 November 2015 at 21:04, Nicol Bolas > > wrote: > > Besides, the committee seems to hate named parameters on general > principle. > > Correction: the committee has multiple times rejected proposals that don't > work. > The parameter names in the library are unspecified, which means that none > of the proposals seen thus far would work with the library. Various > aspiring > proposal authors continue to cite e.g. Common Lisp and Python as examples > where named parameters "just work". The difference there is three-fold: > 1) in those languages, the library parameter names are well-specified > 2) those languages do not suffer from preprocessor macros leaking into > the library implementation, whether standard library or not > 3) library authors, even authors of non-standard libraries, have > reservations > of having to start supporting stable names once the names become part > of the interface. > > All proposals for named parameters have thus far failed to reconcile > those concerns, > regardless of the actual syntax they have proposed. > Six on one hand, half-a-dozen on the other. Having named parameters means parameter names are part of a function's interface. So if people are against that, then they're against named parameters. That being said, I cannot verify if any of the named parameter proposals were ever opt-in. That is, that a function declaration had to use specific syntax to allow itself to be used with named parameters. All of the ones I found seem to assume that any function that gives its parameters names must be callable with named parameters. Requiring opt-in on a per-function basis would seem to satisfy #3: each library author decides if they want to allow the use of named parameters for each function. And if they do, then it is their responsibility to keep the names legitimate. #2 is hardly a fair concern to castigate named parameters over. Macro leakage potentially hurts lots of things, from uses of user-defined literals to many other features. Modules will do what can be done to prevent this, but we shouldn't avoid features out of fear of what macro leakage will cause. -- --- 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_5504_1937590043.1448310867924 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, November 23, 2015 at 2:17:27 PM UTC-5, Ville Voutilainen wrote:<= blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord= er-left: 1px #ccc solid;padding-left: 1ex;">On 23 November 2015 at 21:04, N= icol Bolas <jmck...@gmail.com> wrote:
> Besides, the committee seems to hate named parameters on general p= rinciple.

Correction: the committee has multiple times rejected proposals that do= n't work.
The parameter names in the library are unspecified, which means that no= ne
of the proposals seen thus far would work with the library. Various asp= iring
proposal authors continue to cite e.g. Common Lisp and Python as exampl= es
where named parameters "just work". The difference there is t= hree-fold:
1) in those languages, the library parameter names are well-specified
2) those languages do not suffer from preprocessor macros leaking into
the library implementation, whether standard library or not
3) library authors, even authors of non-standard libraries, have reserv= ations
of having to start supporting stable names once the names become part
of the interface.

All proposals for named parameters have thus far failed to reconcile
those concerns,
regardless of the actual syntax they have proposed.

Six on one hand, half-a-dozen on the other. Havin= g named parameters means parameter names are part of a function's inter= face. So if people are against that, then they're against named paramet= ers.

That being said, I cannot verify if any of the named parameter = proposals were ever opt-in. That is, that a function declaration had to use= specific syntax to allow itself to be used with named parameters. All of t= he ones I found seem to assume that any function that gives its parameters = names must be callable with named parameters.

Requiring opt-in on a = per-function basis would seem to satisfy #3: each library author decides if= they want to allow the use of named parameters for each function. And if t= hey do, then it is their responsibility to keep the names legitimate.
#2 is hardly a fair concern to castigate named parameters over. Macro lea= kage potentially hurts lots of things, from uses of user-defined literals t= o many other features. Modules will do what can be done to prevent this, bu= t we shouldn't avoid features out of fear of what macro leakage will ca= use.

--

---
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_5504_1937590043.1448310867924-- ------=_Part_5503_495297068.1448310867924-- .