220 39844 article Path: news.gmane.org!.POSTED!not-for-mail From: Jake Arkinstall Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: What do we want from named paramaters Date: Thu, 16 Aug 2018 23:19:56 +0100 Lines: 145 Approved: news@gmane.org Message-ID: References: <1534441498.3721109.1476442920.71D445BF@webmail.messagingengine.com> <037bdc3e-6030-41d6-ae70-3849cca0585c@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000007f4a10057394d812" X-Trace: blaine.gmane.org 1534457885 19847 195.159.176.226 (16 Aug 2018 22:18:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 16 Aug 2018 22:18:05 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDCZX3WUUQFRBGHR27NQKGQECB27BJA@isocpp.org Fri Aug 17 00:18:01 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f198.google.com ([209.85.223.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fqQad-0004zc-Kq for gclcip-std-proposals@m.gmane.org; Fri, 17 Aug 2018 00:17:59 +0200 Original-Received: by mail-io0-f198.google.com with SMTP id s3-v6sf5253470iop.4 for ; Thu, 16 Aug 2018 15:20:10 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1534458010; cv=pass; d=google.com; s=arc-20160816; b=C2yaxSCValrwnO0VQvsNFNIgQF3yK73pjRXhSzmbkzeBDxl1nWqH/Fs08Iv5DlhXDg 8F8gaerGlw1DhSUCtTUyOwJfnVu94KMJ4O4kZJjVp05bzZCayIQlld+Z4WCo+NSOEIOr rMLzMvtADR0s8yLXW1CwssvGb/AVNb6dm1Bc408RsnxVFIXsMPp86qfxhVNltYkXbVQ+ eG1T0e42sK3/STY9lcCcffVie9UOSoHCRV/KQYcuhkLviRe31jV4e/q1PYdQ3bE/WoDn cz1boqnlwWRXdyVxvuB2pPGvTfvzkf4CluHE/NB6KNbmaYPP248/jkecl0Y8Lki3VGGy lFww== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:in-reply-to:references:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=BXNpuJqTWAPsYtRtXlagfA9GdfcTD30lNjwrIR9AZSY=; b=XPLd9SIkNKW1btfBYbVD6erjayYN30CKCyH+Q/wEw/7U+nyQl6sjUi1c3cls8NIWVz Mg+SxEZo733C3U3TA4EhR7G3vrSMj4XXimm9nE2XJLWBE6650iZ2qNUQS83hs0CPVScn BU3INnrKautx52BxMfC/e3J3Rf24f6GB9GmbkngIHGJxYixagVN9s0rmMrzYUoBuhbuA QQlgC/cFD6jGiOxc5sRJGBWDm3PZXxpt6iV4s45qhBDCn1LRJekSS1MPO5M3Z9P6xVUr TcfXcez/KeKxiXL4bBymKEOrLvl5sK1q+4dEJFu9NcpIValJo8I75u0h0l73GNkurrQ+ Rkhw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=HHUSuQOI; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=BXNpuJqTWAPsYtRtXlagfA9GdfcTD30lNjwrIR9AZSY=; b=ya5KpXHvUgo07KhqKSnR4XZaKD/61UxmAdxz9+CEsBtBGTauL0tjx+A/1O8C4vd/sJ CVVP9vH+6yqgGmaaGHo6Y1SvmB5vBg56FHkDy70vwUrAwEUlEzZECSZ+4q+tXDChIARr 2Mwi7lGxxFBhi/EKu2i1lWrJi/DxvBZrdHMbrwiiFSo7ju6kJmpxq8KmvpdXVVLCSwZR irpx5Xlu5cC54z6YbovBNq2O5vSMxZkJDRkpMF+nC6dLEqBDzbaRc+uOpV2F2W3/Z54b JH6Nb7BpzW7qyAWAl5hPFJ8A04KoSdtStWYeBH7jPSqr7GuGlGKusRHftA7hjxhqPFN4 0+QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=BXNpuJqTWAPsYtRtXlagfA9GdfcTD30lNjwrIR9AZSY=; b=ACVaMUfNJLJ/JCCHw1UIeTK1eHGHBD1FTKBo2kJU/FCuBMu+xTTTM8Tm3bvnzjfyHo KQz//js3R0uZxdWXMadKw9GsaUiVGWYVPrQVcbs8jcFMg2MAYzV/9iB+pf2yrisFviUb xn6PfAsFD9pJL95EjnwjvG1HSk86XOy+6ZzsdLe/4rHLXsNKEoRmmU4bSR72CHNn4N7w tBxV/85e3JCYBxUIPVR6psphatr25XSjstU6q9XnZ5qzwH/9HanCGQKjTNfnyGIGQA0N ImWET5uZGKLT0/yFJRKH5ckWcyDzi1SPmzOoT8Ff//P+fTdH+1YD3LKj/gVPZEpjcSKW e+Rg== X-Gm-Message-State: AOUpUlGBNlrl86Un7jPKGdqYHVv1BEKUs96eVhXcT90XwtBXYJa454LG GjzAjB/breMmUSEx7o+ITMfUzg== X-Google-Smtp-Source: AA+uWPzn5VxR/d1f6dGH/LcLMr/nczS3JoKn1tjcr+HIBWLl9MA3eatzN2CV4buchxYffcvDrkeC+Q== X-Received: by 2002:a02:4c16:: with SMTP id a22-v6mr15400011jab.9.1534458009930; Thu, 16 Aug 2018 15:20:09 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a02:3801:: with SMTP id b1-v6ls1037698jaa.4.gmail; Thu, 16 Aug 2018 15:20:08 -0700 (PDT) X-Received: by 2002:a02:3344:: with SMTP id k4-v6mr29319515jak.45.1534458008623; Thu, 16 Aug 2018 15:20:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534458008; cv=none; d=google.com; s=arc-20160816; b=XeHuYCkMzljQzh4mjFmpRvj1dlJlrwCNbue7lmn/uFMLrUZOlNYkypPXHy1dlnQ4oL 9cAKZsGqbzeuKOIiocaZUml8kUQNrcjZrbrsrgwQ445zBaumnEDJrkh4TbWkNj3tmqBn Ndk1Ftppm8Mj8pT8iaBEegLjr6fj+A8a5ObRvdf1Qs8H9YPEduqaTkL7Kw+8LFMru5g0 WMG9v3dRzMrIDXHkDLQVvXUK8hBgUBFXNZdIcE+7f9B2b8AuVc399u2oq7k0rlvaXJT+ IA3iIe7UukgOb6hh1PtkJiqhQIpMPCarR7remgZO2mdLVqPaxpGxKXQrA7ES5wKLal+L Qo1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature:arc-authentication-results; bh=2AZdvTIQBLxGrJC8UWiX/6ZKOzd5U4vXzr6zyUL797w=; b=AD90KCEsaFO+GdbavmEEZDrfWWYwWxD2XCWu09huxbrwJ0hXqk12PX2jiFbOZ6ppdC LTbKZeno2/BoxqzlC05nRVvfJ9rbbG4bvOA8fazqMR81lpzuwK0z0Ibfu8/lgQB6LN2g Ppb9j3U8X/t9LF20wyai+1Gsd83iIny2Chr+4sBzkTWj5+5OqPBTva+dLg2N9tnTdL+O VzGsSEMmylL3s2zH4EBPK0h72QnK4Q1BdLTZXgOCPzXMCoP8SpZ2b73C2QcOV7nDmiNL bcqEdnOrZBlvw8kUnA7771cHUWirFQMJilouLIA043OcxelwsV+/gq3WgwFMss2LYM2T 2D1A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=HHUSuQOI; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id f14-v6sor931174ita.130.2018.08.16.15.20.08 for (Google Transport Security); Thu, 16 Aug 2018 15:20:08 -0700 (PDT) Received-SPF: pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a24:5a82:: with SMTP id v124-v6mr2135282ita.78.1534458008126; Thu, 16 Aug 2018 15:20:08 -0700 (PDT) In-Reply-To: X-Original-Sender: jake.arkinstall@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=HHUSuQOI; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=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:39844 Archived-At: --0000000000007f4a10057394d812 Content-Type: text/plain; charset="UTF-8" On Thu, 16 Aug 2018, 22:23 Dejan Milosavljevic, wrote: > Something complexly different approach. > Fro both items ignore syntax, ideas/problems are main focus. > > 1. Strong typedefs. > Currently there is strong demand for for it. > But no consensus so far. > Take a look at next code > > strongdef polar = std::array; > strongdef descartes = std::array; > struct A{ > void f( polar const& p ); > void f( descartes const& p ); > }; > > Clearly strong typedef will supersede this proposal. > This aligns with my viewpoint on this - though it is commonly argued that we might just end up cluttering up code with artificial types. My take on it is that it's always worth doing so in order to define strict conversion rules, but it isn't everyone's cup of tea. > 2. Another nice proposal is call functions with named parameters: > Another very niece feature. > > Example: > void f( int a, int b ); > f( .b=1, .b=2 ); // Highly probable that is one of many proposed > syntax. > I find that syntax ugly, but its something I would get used to after some time. I'd prefer :name, $name, @name, something with a bit more prominence than a dot. But that's just me. I see here another clash. Syntax must be clearly different. So more > complication. > Clash aslo will be in the head of programmer. Which one is call > functions with parameter naming and which one is from this proposal. > > Combining two of them( strongdef and function call ) is very easy. > No interference to from each other. > > Based on previous two item it is not enough to solve current problem. > > It is must to see what is effect on other proposal. > I guess mixing the two approaches would make a lot of sense, and it certainly goes some way to answer the "what if the signature for two functions are the same" problem. Forbid it and make the types stronger if and when you need to. The last thing I want to have is *forced* named parameters because of a confusing API. It's an immediate way of making your headers incompatible with older C++ versions, and I see no justification of such a major language overhall for a feature that won't see any widespread adoption for a decade. On the other hand, it's easy enough for a library to provide structs for strong types for older standard versions, wrapped in preprocessor conditionals. -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNmazfF1R35rWui0D73g258Y0X9RT7XPMa638DMmGf%2BEA%40mail.gmail.com. --0000000000007f4a10057394d812 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, = 16 Aug 2018, 22:23 Dejan Milosavljevic, <dmilos@gmail.com> wrote:
Something comp= lexly different approach.
Fro both items ignore syntax, ideas/pro= blems are main focus.

1.=C2=A0Strong typedefs.
= =C2=A0=C2=A0=C2=A0 Currently there is strong demand for for it.
=C2=A0= =C2=A0=C2=A0 But no consensus so far.
=C2=A0=C2=A0=C2=A0 Take a look at = next code

=C2=A0=C2=A0=C2=A0 strongdef polar =3D std::array<doub= le,2>;
=C2=A0=C2=A0=C2=A0 strongdef descartes =3D std::array<doubl= e,2>;

=C2=A0=C2=A0=C2=A0 struct A{
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 void f( polar const& p );
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 void f( descartes const& p );
=C2=A0=C2=A0=C2= =A0 };

=C2=A0=C2=A0=C2=A0 Clearly strong typedef will superse= de this proposal.
This aligns with my viewpoint on this - though it = is commonly argued that we might just end up cluttering up code with artifi= cial types. My take on it is that it's always worth doing so in order t= o define strict conversion rules, but it isn't everyone's cup of te= a.

=C2=A0 2. Another nice proposal is=C2=A0call f= unctions with named parameters:
=C2=A0=C2=A0=C2=A0 Another very niece fe= ature.

=C2=A0=C2=A0=C2=A0 Example:
=C2=A0=C2=A0=C2=A0=C2=A0 void f= ( int a, int b );
=C2=A0=C2=A0=C2=A0=C2=A0 f( .b=3D1, .b=3D2 ); // Highl= y probable that is one of many proposed syntax.

I find that syntax ugly, but its something I would= get used to after some time. I'd prefer :name, $name, @name, something= with a bit more prominence than a dot. But that's just me.

=C2=A0=C2=A0=C2=A0=C2=A0 I see= here another clash. Syntax must be clearly different. So more complication= ..
=C2=A0=C2=A0=C2=A0=C2=A0 Clash aslo will be in the head of programmer.= Which one is call functions with parameter naming and which one is from th= is proposal.

Combining two of them( strongdef and = function call ) is very easy.
No interference=C2=A0to from each o= ther.

Based on previous two item it is not enough to solve current= problem.

=C2=A0It is must to see what is effect on other proposal.

I guess mixing the two a= pproaches would make a lot of sense, and it certainly goes some way to answ= er the "what if the signature for two functions are the same" pro= blem. Forbid it and make the types stronger if and when you need to. The la= st thing I want to have is forced named parameters because of a conf= using API. It's an immediate way of making your headers incompatible wi= th older C++ versions, and I see no justification of such a major language = overhall for a feature that won't see any widespread adoption for a dec= ade.

On the other hand, = it's easy enough for a library to provide structs for strong types for = older standard versions, wrapped in preprocessor conditionals.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNmaz= fF1R35rWui0D73g258Y0X9RT7XPMa638DMmGf%2BEA%40mail.gmail.com.
--0000000000007f4a10057394d812-- .