220 40826 article Path: news.gmane.org!.POSTED!not-for-mail From: David Brown Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Named parameters Date: Wed, 31 Oct 2018 10:17:10 +0100 Lines: 293 Approved: news@gmane.org Message-ID: References: <00c801d46faf$dc525450$94f6fcf0$@gmail.com> <1540839750.2580417.1558674040.678FE689@webmail.messagingengine.com> <1540943711.521596.1560297152.15CC3529@webmail.messagingengine.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1540977317 26940 195.159.176.226 (31 Oct 2018 09:15:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 31 Oct 2018 09:15:17 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDP6R2XHXIARBIPG4XPAKGQEF6Q5D5A@isocpp.org Wed Oct 31 10:15:13 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lj1-f197.google.com ([209.85.208.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gHmam-0006tk-8R for gclcip-std-proposals@m.gmane.org; Wed, 31 Oct 2018 10:15:12 +0100 Original-Received: by mail-lj1-f197.google.com with SMTP id q65-v6sf1366919ljq.8 for ; Wed, 31 Oct 2018 02:17:23 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1540977443; cv=pass; d=google.com; s=arc-20160816; b=w6J5xzqEZBb+Xta4ZH3Jz64/juuqavGXt+gIv0zzdpZTkFIRM1NfAGa+mjdNpgWPF5 3eVWaVSWetnf7pmzUsPK/gVKM9u8zoU3230FsTb5TfodBkeDjId1nSOh0I9+U+4QzmPJ 8ZyCpL8MKB44jURB0nIlDQ5+6VFBPqDkUcmhNhcgeI0Im02dQQ05mlng0hPuQftGTQ/e TfxD/sJOPxGyiV82WE359PtMDtUD+ZyqJ4tiR/K/h71VGuE1J6pYhfHXMy/oYH3ssclf 6TQXuC6bct2wlJG9A6NqhQ/bwi+PyitqU15zv/5CLnDEs437ex+dV8DUNM8cWq/kED7G 4+1A== 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:in-reply-to:user-agent :mime-version:references:message-id:lines:date:subject:from:to :dkim-signature; bh=zsj79PiVQjC+Zoy3ipTMtxs2GkoqVQ6lRVH4ezNZiEY=; b=Lrm0mcPoyo7W5XDOqRu6DlKUmG0Svf6NJcH1UEN+6vEdXWRl63SdqBzH+g/PBHrjU7 IKdIB7xdPOf9BLsMl8xosf7y1c/JJl+tMybiNvLHAtXeZyRZ1KyyCzlWwo+X7u69dOcP iC/mqst+Kg4xiPNdCgBRy/Hu95ulR/1hLUwChCRLSSqt/ie9kptmM9GTBvhrvywIoGfA EB1M/efHhn2O+VkX1pT/RdP8x6ruRV4hiOJVYDfedwMmHLccKMALNpqFou2EdxcEIR5e Jz+31UD6XWXGBgl+63GboUTkBi29xwZt5H6ii9ZWkBVSLZxymjArlMUJuBxETcRCIVJl v1rw== ARC-Authentication-Results: i=2; mx.google.com; spf=neutral (google.com: 195.159.176.226 is neither permitted nor denied by best guess record for domain of gclcip-std-proposals@m.gmane.org) smtp.mailfrom=gclcip-std-proposals@m.gmane.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=to:from:subject:date:lines:message-id:references:mime-version :user-agent:in-reply-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=zsj79PiVQjC+Zoy3ipTMtxs2GkoqVQ6lRVH4ezNZiEY=; b=jrdt7oqSJclC2D90Rq5oS3odZlktnVaqedeGX3RLoXEc/NlDgBnJYxuRyXjuGEKmnu e7BMlYsNYMzz/QWrn9zpobzoyp/KaGiqlKiASS/BazUzvcaDFYcB0eH6ObtGk9HwIMwI rmspPGdPcxjKXpNPSW+nsHtUU33pV2ha3Pe07CwLMDhmeXAp1tVfEkRHTTme6IGna3Fr UzAldjo5vaLOhmL6hONEG+hfJJQb2YXHWAfCTCRZ30zPI7HjAWuanRADmVaaJuvTB4k1 GgzpGyRQDJIX0Jj3YJwOkptJMzTE8TIMG+vkzcAUx+batmH9N6KluQf+e+lhmBxf3aQn gW6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:date:lines:message-id:references :mime-version:user-agent:in-reply-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=zsj79PiVQjC+Zoy3ipTMtxs2GkoqVQ6lRVH4ezNZiEY=; b=WdyyF10XC+tx3lu/nUwZWGsHX3QzYuiGwlBz6UIa90SMMs6XIX7gpadq//5M+jy8u3 wlzz6RSnRjeycGlJFXxJC2CW0DjiBRLF0orrku4dRzDPpiNqcF2/NPhq8rkQCMu9mu6i tvPNfK7d6SkSCz78f6elznMcxRCY1tGXcVKh7Zf5OJnjz37zy19p6CJw0hHQvzbwxYWd cJYznhwq5XAUtQu01lJeam0SLU2sAEI83qXrNYEcvDB2czF5xM00nHt5gcWx6P2wdiWZ VzeiO5Nu4/bzIOZ5UgG/Ak5yXQGmIxFrnY1RTTjonCtdmX6A11vod7D93Jp6tTLdvt6N 0DGA== X-Gm-Message-State: AGRZ1gIDi1OEv7CE4/syYa5XMM/cJNN35rVtOp38ofvLksY00STJ4peV vYrJFGyegwnnTA5z57qbLCk= X-Google-Smtp-Source: AJdET5da4FQTyJKX6c3Klf3il5UXLmAY73eJ6zGWALHdjNrMIdmOK9VQaqq9VDqgXB0Ii80ZrFwsxA== X-Received: by 2002:a2e:9006:: with SMTP id h6-v6mr191001ljg.22.1540977443041; Wed, 31 Oct 2018 02:17:23 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a2e:874e:: with SMTP id q14-v6ls72781ljj.24.gmail; Wed, 31 Oct 2018 02:17:21 -0700 (PDT) X-Received: by 2002:a2e:20f:: with SMTP id 15-v6mr1431365ljc.141.1540977440991; Wed, 31 Oct 2018 02:17:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540977440; cv=none; d=google.com; s=arc-20160816; b=jNH9jbA4LDHsRYzbUJE8jFl0hcFQ6plg/aygNuTvH64YI5zW8oDKUEtPM8Bqhz9bRe cGaTEQbHR1DON6cfYGMBBouPVEpmRtXTrUd/qqkN4WobeIVk1MzvSJ3Qb5B8rix2YAx3 Ul8dQ+v+LG2hl4YRSYXSzL1QW1shYf+na6V/TGaxzYRZw6IA0Bi/n6xyziSletpRBl1X l7/LQhn1i/0+S2vS+NiYHmeaT4gRCCoQV8I/kzfYLqudwPdRD+Y3vTlshWV1hrXyrdAT KjJx1roUb5bGiEiXUmk/P/aZpQSM3nQyX7jtilpZLs7FxlXENbzrXGvCwuQESPkzkHHQ MCPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:user-agent:content-transfer-encoding:mime-version :references:message-id:lines:date:subject:from:to; bh=FAtW3KcD5PiBhaABCypHCdMqtNPpiiAGswf32J7iGyQ=; b=Wgs3sORyuw0N24vQOuu0wBYpIE8fzcKPqDRGAS+V7vGSuZ/sut94NAKubTmRho5Xg1 OW2Y9MRSxsOalmjeAkCP368rG/EqtPZZBJ6tlHHxDSOOo+HxCRYjfX3uOoTjaPMVH7xH beQCQFHjLtCWlg1ErxEFIkPjE7vQW3Fs07roIy97SfC3yyrsznL+Z2BLdwh2eWm6044H o80+1FS077dTg0Ui3wdJ8Y5G+7uCqT2mlXdpvUVgO8AJ4TfFaBgfWFUMLt6+/6mZvb5D hX2ZntWEWINtBqmy7V8XMm3JAZQ5nnzRV/3rqAADryIQwiLao716uY8obsKG3BW5dR/k ST/w== ARC-Authentication-Results: i=1; mx.google.com; spf=neutral (google.com: 195.159.176.226 is neither permitted nor denied by best guess record for domain of gclcip-std-proposals@m.gmane.org) smtp.mailfrom=gclcip-std-proposals@m.gmane.org Original-Received: from blaine.gmane.org ([195.159.176.226]) by mx.google.com with ESMTPS id r22-v6si7592521ljb.4.2018.10.31.02.17.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Oct 2018 02:17:20 -0700 (PDT) Received-SPF: neutral (google.com: 195.159.176.226 is neither permitted nor denied by best guess record for domain of gclcip-std-proposals@m.gmane.org) client-ip=195.159.176.226; Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1gHmai-0006pU-Uk for std-proposals@isocpp.org; Wed, 31 Oct 2018 10:15:08 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 286 Original-X-Complaints-To: usenet@blaine.gmane.org In-Reply-To: <1540943711.521596.1560297152.15CC3529@webmail.messagingengine.com> X-Original-Sender: david@westcontrol.com X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 195.159.176.226 is neither permitted nor denied by best guess record for domain of gclcip-std-proposals@m.gmane.org) smtp.mailfrom=gclcip-std-proposals@m.gmane.org 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:40826 Archived-At: On 31/10/18 00:55, Henry Miller wrote: > > > > > On Tue, Oct 30, 2018, at 4:27 AM, David Brown wrote: >> On 29/10/18 20:02, Henry Miller wrote: >>> There have been many, all died because of opposition to the idea. >>> You have a syntax, but you need to convince people that there >>> isn't a better way. >>> >>> Strong types are generally preferred. >> >> No, they are not generally preferred. At the moment, they are all >> we've got. >> >> Strong types certainly have their uses, and their advantages over >> other solutions. They also have their disadvantages. > > I haven't actually surveyed the committee, but I think that my > statement stands. I haven't seen anything from the committee either. But even if they have a firm opinion, there is a long way from that to claiming that one method is "generally preferred". The fact that these threads are brought up here again and again, and that there are multiple proposals flying around, shows that there is a great interest in getting named parameters in place and that strong types - or strong types alone - is /not/ the generally preferred. We /have/ strong types today in C++ - it is very, very far from good enough for named parameters. > There is a great desire that if the code compiles > it is correct. > On that, I think we all agree! > Max(left: varShouldBeRight, right: varShouldBeLeft); > > This will compile, but is wrong. That claim makes no sense. Since the syntax does not exist today, it is a matter of how it is implemented. Getting the parameter order wrong will either be a compile-time error, or will be accepted with parameter re-ordering - the jury is still out on which is the best. Silently compiling the incorrect code is not suggested by anyone - that is what we have today, and what we are trying to get away from! Given the declaration: max(int left, int right); and the call: max(right: 12, left: 20); then there are two acceptable options. One is a compile-time error. The second is to treat the call exactly as if it had been written: max(left: 20, right: 12); Everything else is bike-shedding. People disagree on the syntax for the declaration, or if the parameter information should be part of the mangled name of the function, or if it should be possible to have different names for the "named parameters" and the "formal parameter" in the declaration or definition of the function. Some people want to complicate matters with using names to overload functions, others want to keep it simpler. The fact is that most other good, modern programming languages have named parameters. They can make the code clearer, and reduce errors. It can be done in a simple, optional manner that will suffice for the great majority of cases. And it is a frustrating thing to see people arguing about the number of angels that can dance on the head of this pin, instead of just making the clear and obvious solution that people can use today. > In a real program where the > variables come from someplace and are used in multiple locations it > is much more likely that either it fails to compile, or at least > someone catches the error in review. Haskell has a reputation of if > it compiles it is right. It would be nice to have the same reputation > without the downsides of haskell (which are subjective so let's not > argue about them) Ada has that reputation too - and it manages named parameters in a simple manner without strong types. You talk about "real programs". In "real programs", people are not going to go out of their way to make strong types for parameters except in a few extreme cases. When you try to make a solution that requires extra effort on the part of programmers, people will not use it! Make it simple, make it optional, make it work with today's code, and it will be used. > >> A great many people want a simple, clean and optional method of >> naming parameters. It could be nothing more than a compile-time >> check, but it needs a convenient syntax. More advanced >> requirements - re-ordering parameters, forcing the use of names, >> etc., gets more controversial. > > Yes, but why? If you can get the same benefit from something else > that might be better. "Better" for this means simpler to use, with clear syntax and little extra effort. Let those that want strong typing use that - there are cases where it is a good idea, it works today (with lots of boilerplate and ugly code), and no one is taking it away. And for the majority of cases, use a simple system. > >> Parameter naming is not an alternative to strong types, nor are >> strong types an alternative to parameter naming - they are >> complements. >> >>> Why not >>> >>> max(left_t left, right_t right) >>> >>> This does everything you wanted, plus as a user I can use my own >>> names. >>> >> >> It most certainly does not do what /I/ want. >> >>> void fub() { left_t foo(99); right_t bar(getFuzzSize); max(bar, >>> foo) ; } >> >> This separates the declarations from the call site, spoiling the >> point completely. Better would be: >> >> max(right_t(getFussSize), left_t(99)); > > I figured that was obvious, but it fails to show the power of types > vs parameters: types follow to other contexts in a often useful way > that named parameters do not. > I don't care. Really, I don't. What I care about is being able to make a function call in a manner the same as today, with the /option/ of being able to include the parameter names in some way as self-documentation for the code and as an extra check that I have got the order right. >> (Giving the same compile-time error.) >> >> But let us be more realistic. Suppose "max" is in the namespace >> "stuff". Types "left_t" and "right_t" are specific to the >> function "max" here, and should be in a nested namespace >> "max_params" so that they are independent from "left_t" and >> "right_t" for other functions. That gives us: >> >> stuff::max( stuff::max_params::right_t(getFussSize), >> stuff::max_params::left_t(99) ); > > Should be stuff::right_t. No, it should not. "max" is a silly example here, as are "right" and "left". A better example would be: guilib::drawbox(int x1, int y1, int x2, int y2); Are you telling me you think "x1_t", "x2_t", "y1_t" and "y2_t" should all be types within the "guilib" namespace? Are you telling me that there should a type within the "guilib" namespace for each of the parameters for each of the hundred functions in that namespace? Are you telling me that the "x2_t" type for parameter "x2" in the "drawbox" call should be the same as the type for parameter "x2" in the "beziercurve" call where it means a subtly different thing? What about in the "sheartransform" call in which "x2" is now a floating point type rather than an integer type? > That max takes this isn't a factor. The > very name max implies there is a min which should use the same types. > Most likely stuff is a larger name space with lots of functions that > take or return left_t and/or right_t. They are conceptually the same > type and it would make the library hard to use if they were not the > same type all the way through. You are talking about a different thing entirely. You are not talking about using strong types for parameter naming - you are talking about using strong types in programming in general. Strong types are, of course, a good idea. (The C++ language today makes it too difficult to make them - it takes too much manual coding. Some standardised libraries for the purpose would be a good idea, but maybe it should wait until metaclasses are in place.) But strong types of the sort you are describing are /not/ an alternative to named parameters - they are a complement. So for the "guilib::drawbox" example, it would be better to have type such as "guilib::pixel_coordinate_t", used for the parameters in "drawbox". (Perhaps this should be split into horizontal and vertical types, or combined as a point type - that's a minor detail.) But that does not help in the slightest to get the parameter order correct. It helps distinguish between a two-point style "drawbox" and a point plus height/width style "drawbox". But it does not help avoid mistakes such as "drawbox(x1, x2, y1, y2)". To do that using strong types, you need a new strong type for each parameter. For each parameter, in each function call. This is doable, but would need the kind of changes I proposed in order to be manageable. > >> Compare that to a named parameter solution of : >> >> stuff::max(right: getFussSize, left: 99); >> >> There is simply no contest. > > A simple using can bring right_t into the current scope and solve > that. Now we have the same thing as below. I don't want to have to add "using" clauses for every parameter of every function call. Such extra code makes the program harder to read, which is always a bad thing. But I /do/ want to be able to add parameter names to every parameter of every function call, if I feel it makes the code clearer or safer. > >> >> If there is to be a sane use of strong types as a way of >> implementing named parameters, we need two things. >> >> First, we need a "function parameter scope" for lookups, so that >> within function parameters the identifier lookup starts with a >> scope for function. This should also include scopes related to the >> parameters (if a function takes an enum parameter, you should be >> able to use enum constants of that type directly without giving the >> scope details). >> >> This gets us to a call: >> >> stuff::max(right_t(getFussSize), left_t(99)); > > A proposal to make function call parameters follow different type > resolution rules from the outside scope probably is a good idea. > There are some tricky areas in some of the details that need to be > worked out, but it seems realistic. I'm not thinking about it, but I > see the use. I am confident that there would be tricky areas - there are /always/ tricky areas :-) But I am also confident that it could make code simpler to write and simpler to read. > >> Secondly, we need syntactic sugar so that when declaring >> stuff::max, we don't need to define the parameter types and scopes >> manually. >> > > That is the downside to strong types in current c++. They require > something ugly (very subjective, some people are happy with their way > of overcoming the problem some are not) > Yes. As I mentioned above, I think it might be best to wait until metaclasses are in place before "solving" this one. I suspect that metaclasses could be used to give a much neater solution, both from the users' viewpoint and from the implementers (it would just be a new standard header or module, rather than changes to the core language), and it would be a shame to standardise on one method when a better one is around the corner. -- 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/prbrqm%24p6o%241%40blaine.gmane.org. .