220 22881 <82e9113a-66fb-4786-bafe-2eac0151dacc@isocpp.org> article Path: news.gmane.org!not-for-mail From: Hannes Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Designated initializer list status? Date: Tue, 24 Nov 2015 09:13:27 -0800 (PST) Lines: 140 Approved: news@gmane.org Message-ID: <82e9113a-66fb-4786-bafe-2eac0151dacc@isocpp.org> References: <8b5cda67-8c22-41b6-b99d-ac2ab22f30d2@isocpp.org> <20118093.Wcnva6JXIr@tjmaciei-mobl4> <3605168.XWA2AUuY0G@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_7147_1069415346.1448385207122" X-Trace: ger.gmane.org 1448385212 30106 80.91.229.3 (24 Nov 2015 17:13:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 24 Nov 2015 17:13:32 +0000 (UTC) Cc: landeholm@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDY2JDVXYMMRBOFV2KZAKGQEDRW3QVI@isocpp.org Tue Nov 24 18:13:30 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f72.google.com ([209.85.220.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a1H9k-0006es-41 for gclcip-std-proposals@m.gmane.org; Tue, 24 Nov 2015 18:13:28 +0100 Original-Received: by pacdm15 with SMTP id dm15sf72524477pac.1 for ; Tue, 24 Nov 2015 09:13:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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=hOhtt6EJihBxrm6e3VlyOV7rX5pRwLdlGADSnC8wpBY=; b=yDZNpPpIXNXqOjQ3tRC+5YpJuarYb9Mc0pkQ2I/h5vLF6vbeKHBo8MCNWQ5bR2M7eE CaPzfq6Ube/qJehjx5Gb+RHr/CKofaUNZXjbNMijxUponhMFPbxjVKxuWFF+Surs+at3 Tyvslo0fprJTwqDl1Vg4Y3FR4VhLfvyyrbMX6TmEQqD9pFMZiir40AZQUAALDa6vG3Wb RWgE3opIoRURIFmUnZoJMHJq2RGQL0L+sXt25vzt29pYgw6iHA+vjGCxl1iwrWoTkITX GTh4NItYK8y3xW5/WyEtkF9+xBNypCx3rvxEURz5WqdS6DPTcqaOsWsyaxYgg/psY1w9 zl8Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc: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=hOhtt6EJihBxrm6e3VlyOV7rX5pRwLdlGADSnC8wpBY=; b=uHngTITXrGzL5iL284oKTqxBi/6Fru9U4646KWHGSrgLoy/dd4QAxmZ0prcXgn3dEJ JpGLtOiR2t79C5U1gqWGLg6BUxd/hl9l8VQdAG5E04Rw0j78XfEvC4yqw4DOJE1/k2Rb 7LjJSJopKYMEVoRES53PfBangCC0s8g+MLP3iFTaHyT96kzTbU0kBUMGF7ZDKqgmshdc OGPreOY2oKJdbPjpiiOQxZX78HxYZYCe8tZO7+nEzap6pksVO6sj8OqxM5QPaDuC7M1e vViSGH11oYdKndN6yN5jltM8mTnAxoTnHaDywtCDF3smbi4DNqqik3pM8iXcw9MKUZ9L /DTA== 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:cc: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=hOhtt6EJihBxrm6e3VlyOV7rX5pRwLdlGADSnC8wpBY=; b=FTufIOjrVeq+VsTZLksau68UXw0AL+knjFnpCvKisYHaQmub2fyi4604MIjsL8UAm8 T1gSBIjZK45xw2/siSbiBYOGwgeZPp1Kig7/or5w2RbaUEhVCfgBhRYSsUwXEkF/it/V qiVGy/+ZrAgLHinNPVyDw1limeNXv8Sus+5w3eKXMGUOV4lLehdbKIJTbMNNvCaImxTY rPEwJSm1ptiO3B5/sJI/Sp/wNX1kC1mZ0PL8uzWuAK/u2jYyiMZVM4gHXAexH4zsVR1b yaKxSRNja/Uy3LDym4BQ9RyL7m/PXzJUVRyZsY8vUEPNtGARiHo6m66AJ6Bl10n02nXV 7B0w== X-Gm-Message-State: ALoCoQnf4xbXSCqcQZ1j93wx6z0Ehp52wm2dOPlcXgujO7ClaqGDkPqs0eXSMpRYc64++prmM4yF X-Received: by 10.66.219.99 with SMTP id pn3mr31673653pac.9.1448385208717; Tue, 24 Nov 2015 09:13:28 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.161.78 with SMTP id k75ls395972ioe.39.gmail; Tue, 24 Nov 2015 09:13:27 -0800 (PST) X-Received: by 10.50.57.100 with SMTP id h4mr485212igq.6.1448385207942; Tue, 24 Nov 2015 09:13:27 -0800 (PST) In-Reply-To: <3605168.XWA2AUuY0G@tjmaciei-mobl4> X-Original-Sender: landeholm@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:22881 Archived-At: ------=_Part_7147_1069415346.1448385207122 Content-Type: multipart/alternative; boundary="----=_Part_7148_439324555.1448385207122" ------=_Part_7148_439324555.1448385207122 Content-Type: text/plain; charset=UTF-8 On Tuesday, November 24, 2015 at 4:38:58 PM UTC+1, Thiago Macieira wrote: > > I don't think anonymous structs are required. The point is that you should > never have to name them, so whether they are anonymous or not is entirely > orthogonal to the issue. > It solves the problem where the library would be forced to expose a new standardized aggregate type name in the API to application code. Allowing anonymous structs would allow the library to force the application code to use unnamed initializer lists. > Doesn't all first entries in each pair cause an ambiguous overload > resolution? > The parameter n appears in both structures and both structures have an > integral as their first argument. > Yes, this is currently ambiguous with aggregate initialization. However the idea was to introduce more overloading priority rules to make it analogous to parameter overloading, e.g. select the anonymous struct with the fewest unspecified/default fields. That said the anonymous struct thing is just a silly idea I had. Personally I completely agree with Nicol that designated initializers should just be considered an extension to aggregate initialization and has nothing to do with this named parameter business. TCO requires that the callee can pop the stack of the caller. That cannot > happen if the caller had to allocate space for the parameters on the > stack. > You're right, I made a premature assumption that the memory was owned by the callee but I now realize that would always force memory copy and thus be inefficient. > The point is simply that using a struct in lieu of actual parameters is > not > guaranteed to have the same ABI calling conventions, which may prevent TCO > from happening and quite often will have worse performance for one reason > or > another. > This is getting really off-topic now IMO but my counterpoint to that would be that if someone is concerned with the performance loss from some stack spillage they should consider link-time optimization anyway which makes the ABI irrelevant. -- --- 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_7148_439324555.1448385207122 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tuesday, November 24, 2015 at 4:38:58 PM UTC+1, Thi= ago Macieira wrote:
I don't= think anonymous structs are required. The point is that you should=20
never have to name them, so whether they are anonymous or not is entire= ly=20
orthogonal to the issue.

It solves the problem where the librar= y would be forced to expose a new standardized aggregate type name in the A= PI to application code. Allowing anonymous structs would allow the library = to force the application code to use unnamed initializer lists.
<= br>
=C2=A0
Does= n't all first entries in each pair cause an ambiguous overload resoluti= on?=20
The parameter n appears in both structures and both structures have an= =20
integral as their first argument.

Yes, this is currently ambiguous with = aggregate initialization. However the idea was to introduce more overloadin= g priority rules to make it analogous to parameter overloading, e.g. select= the anonymous struct with the fewest unspecified/default fields.

That said the anonymous struct thing is just a silly idea I= had. Personally I completely agree with Nicol that designated initializers= should just be considered an extension to aggregate initialization and has= nothing to do with this named parameter business.

TCO requires that the callee can p= op the stack of the caller. That cannot=20
happen if the caller had to allocate space for the parameters on the st= ack.

You're right, I made a premature a= ssumption that the memory was owned by the callee but I now realize that wo= uld always force memory copy and thus be inefficient.

<= blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord= er-left: 1px #ccc solid;padding-left: 1ex;">
The point is simply that using a struct in lieu of actual parameters is= not=20
guaranteed to have the same ABI calling conventions, which may prevent = TCO=20
from happening and quite often will have worse performance for one reas= on or=20
another.

This is getting really off-topic now I= MO but my counterpoint to that would be that if someone is concerned with t= he performance loss from some stack spillage they should consider link-time= optimization anyway which makes the ABI irrelevant.

--

---
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_7148_439324555.1448385207122-- ------=_Part_7147_1069415346.1448385207122-- .