220 40064 <28f2a655-1a1b-4386-9f76-c16ddb1647e6@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: mihailnajdenov@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Named Parameters for C++ Date: Mon, 27 Aug 2018 14:45:27 -0700 (PDT) Lines: 218 Approved: news@gmane.org Message-ID: <28f2a655-1a1b-4386-9f76-c16ddb1647e6@isocpp.org> References: <5d064165-5a58-4810-90f7-aa3732be92db@isocpp.org> <60449422-b543-4949-557a-96435c1c2926@technion.ac.il> <3e50834d-2e56-392f-fe30-8c24769d7647@gmail.com> <44b180b7-9c2f-48fe-9cf5-5b803b45f460@isocpp.org> <0341abf7-070d-4dd6-88d3-b7072b991cd4@isocpp.org> <0fe2a8da-3442-edbe-7bdf-40d6b1c90d1b@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1135_2077566935.1535406327106" X-Trace: blaine.gmane.org 1535406204 10441 195.159.176.226 (27 Aug 2018 21:43:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 27 Aug 2018 21:43:24 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRB57BSHOAKGQEXQUHAOY@isocpp.org Mon Aug 27 23:43:20 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f198.google.com ([209.85.213.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fuPI7-0002cl-No for gclcip-std-proposals@m.gmane.org; Mon, 27 Aug 2018 23:43:19 +0200 Original-Received: by mail-yb0-f198.google.com with SMTP id f124-v6sf305879yba.5 for ; Mon, 27 Aug 2018 14:45:29 -0700 (PDT) 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:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=qaRvWY7Dot1rWYjsgC/876AuP33Bt958wJHnV1WxJGY=; b=nZIXAern9JUga6Sg8099QO0379fxdfztmwvu3WJuCDjCChJDLnVDdp/JnY+59X6fcq OAizisujXe4SBS3aEOpT52Pn8cVJYc8DLtnsxp2yvdMQpX/MiCBhP37YHQU/D1K6ONrD kvRcdRPoIpMWQpQ3hRmv4XsgGnfPZx4TW8N1WYvYXcY03YMuM1hZxJNJKRWJkHJicYGy Kumv+2uy2nDMGi2agtoj6biOi6W79fb5Y1ewzuBGxXq3+SMfru+CSEoaSmkFoogPvP55 MpdCwhm4wmmdyYJPLUEp54w16G9+cXydV8pFj42jatJB+4FNZN/5Gn5XwEzxW7NH089F 158g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc: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; bh=qaRvWY7Dot1rWYjsgC/876AuP33Bt958wJHnV1WxJGY=; b=GibchTYGr4msqUF6Lyvknp4+wXmkNli5Bk0+howVdp73aLVq0uDIIoXhhBz/LUeYEe EXfSSOiKZWk2XkePMVB9oBvGNxYVEMS2mjj1AqAZHje5YoNSG2chfX5tQMwCUOMYm5/K w4CUOwN55Y21WLhubIgyGmU6aynrfD5Lhpi1KWO0hPQZLwzBtm1pUSXjbJoPDIaCEsy/ ufI7vwYeKs0T/LEtyv9aLXOnRqGM/r5RjK7x+Dw2K2ngavnzn6FGtCdPMDL7EdMxm2Ff rf8ukeAol+YgQD8Ol2Zn1CF/o9U/rxJGmbvFkGuroC4pcsYGj8r3OpZsSusESmZgu0HO W0UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version: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=qaRvWY7Dot1rWYjsgC/876AuP33Bt958wJHnV1WxJGY=; b=iz5rxQlOVl2y5vb/3uLaIC3vqYw87MwSze0TGhgV0EECMO2UFmmI+jdmnKFUtT/bL/ K8fVJYA8qtOWoFe29jzqXxDgwuXaJsxKXJz2DiVRWx6v1fq6sxAPdP/JLsa10wQocG6N zPBgfVoRMXRDRnJJlmdXPyo6Ajqx20k63NVWh/DkZNVPIP6F98CaKHNQmkPkc9gQyDUp 7k70pJCMPMtk9EWpLATdoBEr/jtfUWWDZ/c12wnj5IejVB21Irhl1Q+S2D9w1AvI2Wm7 wokQgOe8I+OOD8JixPGAHDkTtyqLFILZS/VUaWOqcRzemNqBB7Mr/uPXUnzrVbW7qOof EaMw== X-Gm-Message-State: APzg51AsNodXfwgxqJWNy+aVyNNhKz1ehvs09J1gAVu5p7LNUUoVmIsT 4/nBJvbpwjrBV9Y0xXinJkW+Zg== X-Google-Smtp-Source: ANB0VdaZ1tRurN7X/wTGOuAA4XhEb5ne6Hma4idsS+oLOnc3LRbq1BLh8uzmx/x5LuWUw7lbsTA8PQ== X-Received: by 2002:a81:218b:: with SMTP id h133-v6mr218067ywh.17.1535406329406; Mon, 27 Aug 2018 14:45:29 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:73d5:: with SMTP id o204-v6ls77649ywc.6.gmail; Mon, 27 Aug 2018 14:45:27 -0700 (PDT) X-Received: by 2002:a81:308e:: with SMTP id w136-v6mr5937yww.0.1535406327691; Mon, 27 Aug 2018 14:45:27 -0700 (PDT) In-Reply-To: <0fe2a8da-3442-edbe-7bdf-40d6b1c90d1b@gmail.com> X-Original-Sender: MihailNajdenov@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:40064 Archived-At: ------=_Part_1135_2077566935.1535406327106 Content-Type: multipart/alternative; boundary="----=_Part_1136_1293118794.1535406327106" ------=_Part_1136_1293118794.1535406327106 Content-Type: text/plain; charset="UTF-8" On Monday, August 27, 2018 at 11:59:44 PM UTC+3, Matthew Woehlke wrote: > > On 2018-08-27 16:38, mihailn...@gmail.com wrote: > > So, *all* arguments are optional, basically strong names with implicit > > conversion from the type. > > Right. > > > struct a > > { > > a(int) {} > > }; > > > > struct b > > { > > b(int) {} > > }; > > > > void func(a) {} > > void func(b) {} > > void func(b, int) {} > > > > int main() > > { > > func(5); //< fails > > func(a(5)); //< ok > > func(5,5); //< ok > > } > > > > Something like that > > Right. > > > Some people will still prefer the zero-overhead compiler-only C#-like > names > > (accepting their limitations), and use a tags from time to time or > > something else or have also have some strong names (or better tags), as > > precision strike to fight overloading issues, but only when required. > > Changing the signature is required for name-based overloading to work. > If we *don't* do that, we basically close ourselves off from *ever* > having name-based overloading. > Well, not without a spin on the declaration. I am worried, your suggestion is dangerously close to P0671R0 that "introduces a new function type", where here every single named argument is changed, which might as well mean *every argument, *which in turn is essentially a new function "type" altogether. Am I also worried, it will be seen an easy way around the need of types. This will be used against it* for sure*. It will probably be somewhat valid argument if we examine current practice in the face of Swift/ObjectiveC - the typing is *laughable* - "dictionary", "data", "string" all over the place. It is the most (the only?) complete solution but it is also the most aggressive one. > > That said, one of the "co-features" I am looking at is the ability to > *alias* functions, differing only by argument names. IOW: > > void foo(int); > using foo(int .x) = foo(int); > > ...says to pretend that `foo(int .x)` exists, but that any call that > resolves to that shall actually call `foo(int)`. Also, `foo(1)` would > not be ambiguous, because even though both `foo(int)` and `foo(int .x)` > are viable, they are actually the same function and therefore are not > considered ambiguous. > > (Note: `using foo(int .a) = foo(int .x)` is also legal. You just can't > mix parameter *types*, i.e. no `using foo(int) = foo(short)`.) > > I wouldn't recommend this for *new* development, but it provides a way > to get all the goodies of named arguments with "legacy" ABI's. > > -- > Matthew > -- 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/28f2a655-1a1b-4386-9f76-c16ddb1647e6%40isocpp.org. ------=_Part_1136_1293118794.1535406327106 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Monday, August 27, 2018 at 11:59:44 PM UTC+3, M= atthew Woehlke wrote:
On 2018-0= 8-27 16:38, mihailn...@gmail.com wrote:
> So, *all* arguments are optional, basically strong names with impl= icit=20
> conversion from the type.=20

Right.

> struct a
> {
> =C2=A0 a(int) {}
> };
>=20
> struct b
> {
> =C2=A0 b(int) {}
> };
>=20
> void func(a) {}
> void func(b) {}
> void func(b, int) {}
>=20
> int main()
> {
> =C2=A0 func(5); //< fails
> =C2=A0 func(a(5)); //< ok
> =C2=A0 func(5,5); //< ok
> }
>=20
> Something like that

Right.

> Some people will still prefer the zero-overhead compiler-only C#-l= ike names=20
> (accepting their limitations), and use a tags from time to time or= =20
> something else or have also have some strong names (or better tags= ), as=20
> precision strike to fight overloading issues, but only when requir= ed.

Changing the signature is required for name-based overloading to work.
If we *don't* do that, we basically close ourselves off from *ever*
having name-based overloading.

Well, not without a spin on the declar= ation.


I am worried, your suggestio= n is dangerously close to=C2=A0P0671R0 that "introduces a new function type", where here every sing= le named argument is changed,=C2=A0
which might as well mean e= very argument, which in turn is essentially a new function "type&q= uot; altogether.

Am I also worried, it will be see= n an easy way around the need of types. This will be used against it for= sure.=C2=A0
It will probably be somewhat valid argument if w= e examine current practice in the face of Swift/ObjectiveC - the typing is = laughable - "dictionary", "data", "string&q= uot; all over the place.

It is the most (the only?= ) complete solution but it is also the most aggressive one.=C2=A0
=C2=A0

That said, one of the "co-features" I am looking at is the ab= ility to
*alias* functions, differing only by argument names. IOW:

=C2=A0 void foo(int);
=C2=A0 using foo(int .x) =3D foo(int);

...says to pretend that `foo(int .x)` exists, but that any call that
resolves to that shall actually call `foo(int)`. Also, `foo(1)` would
not be ambiguous, because even though both `foo(int)` and `foo(int .x)`
are viable, they are actually the same function and therefore are not
considered ambiguous.

(Note: `using foo(int .a) =3D foo(int .x)` is also legal. You just can&= #39;t
mix parameter *types*, i.e. no `using foo(int) =3D foo(short)`.)

I wouldn't recommend this for *new* development, but it provides a = way
to get all the goodies of named arguments with "legacy" ABI&#= 39;s.

--=20
Matthew

--
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/28f2a655-1a1b-4386-9f76-c16ddb1647e6= %40isocpp.org.
------=_Part_1136_1293118794.1535406327106-- ------=_Part_1135_2077566935.1535406327106-- .