220 39862 article Path: news.gmane.org!.POSTED!not-for-mail From: David Brown Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: What do we want from named paramaters Date: Fri, 17 Aug 2018 17:09:30 +0200 Lines: 237 Approved: news@gmane.org Message-ID: References: <1534441498.3721109.1476442920.71D445BF@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 1534518453 10918 195.159.176.226 (17 Aug 2018 15:07:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 17 Aug 2018 15:07:33 +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+bncBDP6R2XHXIARBMWK3PNQKGQELQ3T5DI@isocpp.org Fri Aug 17 17:07:29 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf1-f71.google.com ([209.85.167.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fqgLX-0002jv-U6 for gclcip-std-proposals@m.gmane.org; Fri, 17 Aug 2018 17:07:27 +0200 Original-Received: by mail-lf1-f71.google.com with SMTP id b26-v6sf2064638lfa.14 for ; Fri, 17 Aug 2018 08:09:38 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1534518578; cv=pass; d=google.com; s=arc-20160816; b=Xse1R4xX9XqWD7LSGgZhSMweRsPIvfsFDnIJsolrZmaEFFgTLI2Hr3SRfO/i2XF8OO 8zzDs0r/1p7GKQ/pbDveJvw0QiIgKMN3Epiif8uFOxHb2fnrVF/jNBlKD4Ed9LR047kS jRtIu+j/5Gse5e/B5MdY7p+7STcgiRvPBtlmUf7KYolY+y6mIOB18ljn50bQsJREobSn DNojySMJ9hcqyKJvHQOY0qwT/MYl5enMoLgEiqT4CGoaZyY6AKVZFH7Hzg3jInX05XOz U2pTfMEv/oOiSp7+xPCAtqfcrZZ5kvWoTiGZ0HSOZa8hAIeaypwzKjHAGnFc35fokShq Ilyg== 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 :arc-authentication-results:arc-message-signature:dkim-signature :arc-authentication-results; bh=Sr9DJgV9o6ACxx5JI0iMxA5CMDEeZhkg3FpNLjs445s=; b=bh/vdQUOCUzu4c2k/+/JpRujDfaz1aOlQ6d/GV8kbNEX47vHV1wMa9ngq6BdNYOIIh 9mgDUGbktfzbW0J1OVIqzdtbktkDP0cR/LPjHeUFzVK1j5LgY59+CVGVD40mayx3ioz8 DF1Wd8ZUcJ0y8zN/SeG2t/3tFx4CX+CAcz+pO1f9x/WO2ntQFIUTuEDQu/hD06dCqtWV V5Kwl+Oyq/bZw0B9vEJEAjBm9cu+kaHRFCorUwXHiTZj2j2Zh62AzRO25/7d9YaYmQX4 xp2Ccrg70FHxXltZozjslCfPHJMDMpxZNgnxm9+VVpophRPWIDcuWCqi+IH4+cTBD3ga QfTw== 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=Sr9DJgV9o6ACxx5JI0iMxA5CMDEeZhkg3FpNLjs445s=; b=t7gXwvLl9GZXjmZEXZid8ygDeyTJnyu0dxXfiSBou4YUHseAIQjGUARfnrhy5I32Hc NJlrppAWSxrFQnonEON+TJIeys6Wyg9qb1ZZWMV3hdtu116GNne16bxsgbGg9UcQK3oI WEn6xWuP+NB44aqHmI3RwDEKzapsnwnu/EHrQ8U8A70oqXGsqvrhd5qjCM1cmQLYPC00 iIKwShiKjnlJF1qjAx5yZLCMBADpQp14N0cE7PUViLVCMyNMQB3u6G+WJOsSejv9zxxJ TFyj2kwh4ECIGldja3gjGTDHZlH85o3dHkK8Mbk/fs0igYsEOuggRFZq1SPn1edtiuTl ftTg== 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=Sr9DJgV9o6ACxx5JI0iMxA5CMDEeZhkg3FpNLjs445s=; b=OOILyu4MO/PVG2fCJNDbRgu9II2e2T6QqEm57zUvnjD73c54stymN7CVoXS0oVwbsT +DwMn2j3uL25cOS040egiugFPv92M3E2RT6P8l6AeaTBYdqmQCm+5y//SFws/vbos8sL 4/R/fXIjBIacjqnl9zCR9UZz+NOI0xTwKzI6n1DgjWTQ/q5v3Q2DmIr1IxpRTpAvccvF zC7e4HFO/BpGUfUP14lQVNE/lmtI/nS3ayXoBIlbbvmTC3z0KaSHOm/qW2WLPk33bEzd bMyapXYagNhDOr/5rzo4jps6rTnwnJmFzbCCF56R3wEIQzlo/EIGxx8tHMsW49j83rFQ dyiA== X-Gm-Message-State: AOUpUlF7t+8iLi23Am5CrzE+bi050o2MM6TI1xKHOOvLby9Z8Dp2Vp87 SWuerJB3zDbyd4ZszsG0QuY= X-Google-Smtp-Source: AA+uWPyAqfbiwrFR1oTZUi663Wd/sHuN1AGdc2JkUO8489BJ3EIUDzu2VkxDBfn557Np6uJ4qtZEQQ== X-Received: by 2002:a2e:350b:: with SMTP id z11-v6mr1551854ljz.6.1534518578769; Fri, 17 Aug 2018 08:09:38 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a19:d484:: with SMTP id l126-v6ls458469lfg.24.gmail; Fri, 17 Aug 2018 08:09:37 -0700 (PDT) X-Received: by 2002:a19:fc3:: with SMTP id 64-v6mr22162955lfp.46.1534518577554; Fri, 17 Aug 2018 08:09:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534518577; cv=none; d=google.com; s=arc-20160816; b=KBlxBAkRygaOO+nd2LEiZxIF7LxJCZycStPD+Sw/eZHryHWYCa/3ZDjxtz9xUvKWq4 HmjTrDptkDg561YS1ZW31LP+WJlAa9WMS/ymUjSTAxoJ8MlT5aQ2xDhYYHpQVygBFw9R wJf2cyJghk/JaxWKTSYa38QTS7/djYVIyKedBcVHTdI6ugAtOuHqf53TcrXG/p5ZP6Jd lD4MUBlCInbvmPwwJ2c7dAR9bb9MwkwiHJVas6R4FYqsmp/+sh02+wzQd6poKISHDDca rSLPBoXuk+OHlxxu2s1QZIfl4nsA4AkoreShOh9Oea9z2r73BU+OO3zKPLbEZrIk5mYM cECg== 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 :arc-authentication-results; bh=fLcbjIb37C1ZkG2qIgpWGgsPXIwejcEWHwgU15tWWs4=; b=Bw1bb2bjadTrU3ch32tAhBQbBVDgwf7DpOzWKOBC1eyfkRQdXQt7s4hk5GSuWEdUty W9mt0wmGtUmnpbfHlZ1kCkxGbhh2MRhrIv7ppfNXv6nmOQaJh35xl+min6nOFyrFLfqz YMNgCsTGaICmqgR5Kh979qHIkmoRJcL9mlbZ4FV6eQfdDYaBEWm0MKJcm3n1cNCNZHUw YyG3+2HL7YjXfnvf0ntxdDL/3F67puvNT2g0G+0cZQ9ChssHlxoksiV0Q5XooDHg9ng6 k5q5yRX1n1TBfZ8tKO1wQZ3eeCZOxn7zn3TjOAO3R+NekDJ3frh43cLUn2wVCLYP33j4 V+nA== 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 n24-v6si937462ljg.172.2018.08.17.08.09.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Aug 2018 08:09:37 -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 1fqgLV-0002hY-CE for std-proposals@isocpp.org; Fri, 17 Aug 2018 17:07:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 230 Original-X-Complaints-To: usenet@blaine.gmane.org In-Reply-To: <1534441498.3721109.1476442920.71D445BF@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:39862 Archived-At: On 16/08/18 19:44, Henry Miller wrote: > > In the past couple months I've seen several proposals for names > parameters. Each with a list of pros and cons, and because there are > cons arguments against them. I think we need a discussion on what we > want assuming some strawman acceptable syntax, and some thought of > how many limitations in corner cases we are willing to accept. > > I can think of 4 uses for names parameters. (If you don't understand > these I have simple code examples) > > 1 . a function with more than one parameter of the same type is > called with the parameters in the wrong order > * Some people want this to be a compilation error, some want the > compiler to correct the problem and continue Ideally, I'd want the compiler to correct it (i.e., re-arrange the parameter order). But I'd be okay with an error as a second-best choice. An error is enough to ensure that the code is more readable and mistakes in parameter order are caught. Re-arranging is about convenience in writing the code, which is a lot less important. > 2. a function wants to take the same type to mean different things in > different contexts You mean function overloads based on parameter names? They would occasionally be useful, but not essential IMHO. I'd like them but I would not want them to break other important points like compatibility with existing code and tools (this feature should not cost anything if it is not used). > 3. it isn't obvious from the type alone what a parameter means I have an alternative idea for your example below. > 4. A function has a bunch of defaulted arguments and you want to > change one of the latter ones without specifying all the others This would be convenient for some types of coding, but is not an essential. It would rely on being able to re-order parameters using names. > > First question: is this complete? I think so, yes - those are the key uses. My prime motivation for wanting named parameters is to be able to be sure the code I write is clear and correct, rather than allowing new kinds of coding. #1 above would be sufficient for that. But there are a few other requirements I would add. 5. Using named parameters should be optional unless unavoidable (such as for overloads). The solution should not affect existing code, it should be possible to use named parameters with existing functions, it should not involve any change to generated code, mangled names, ABIs, object code formats, etc., unless unavoidable (again, we are talking about overalods). 6. It should be suitable for use in C as well as C++ (excluding overloads). I don't expect it to be part of the C standards until perhaps C38 (when we have all retired early to avoid the year 2038 fallout) as they are very slow to adopt new features. But I would expect big C/C++ compilers to support it as an extension in C once it is part of C++. > Second, which problems are worth solving? #1 is definitely worth solving. The others would be nice as long as they don't delay a solution to #1. Parameter name based overloading looks challenging and would involve a good deal more changes to the language and the tools. It is worth considering, but may not be worth solving. There could be alternative ways to get this effect. > Third, for problems worth solving, which is the better solution, and > how strongly attached to it are you? My proposal in the other thread is the best solution :-) > > For the first the motivating code is something like: > > class myMatrix { > T GetCell(int row, int column); > ... > }; > > in code: cell = matrix.GetCell(column, row); > > This will compile just fine in C++17, but the code is undoubtedly > wrong. In C++2n do you want this to be a compiler error, or correct > code? I don't think it is an appropriate example. If you have: int column = 1; int row = 2; auto cell = matrix.GetCell(column, row); then it should compile fine. It is not using named parameters, but is existing code. (A smart compiler could warn about it.) But /this/ should either be an error, or be re-arranged automatically: auto cell = matrix.GetCell(.column = column, .row = row); > > > Second: > class point { > point(double x, double y); > point(double distance, double angle); > ... > }; > > This code does not compile in C++17. Do we want to make this case > work? I'd be okay with allowing it, but it would involve a lot more changes to support. See the next case below. > > > Third: > class myString { > int compare(myString, bool CaseSensitive); > ... > }; > > in code > if(str.compare(otherString, false) == 0) ... > > // what does this mean, why would you call compare and not compare? > > This code is legal C++17, but it is user hostile. False in the > context of reading the function makes no intuitive sense. Qt has > created an enum for this, but it can be argued that this is too > heavy. (you may or may not agree with the argument) The ideal solution, IMHO, involves two parts. I would like to see function parameter scope types, and perhaps be able to define them within a function declaration. I want to see: class myString { int compare( myString, enum class CaseSensitivity { insensitive, sensitive } sensitivity ); Then you could write: if (str.compare(otherString, insensitive) == 0) ... The "insensitive" would automatically be looked up in the scope of types declared within the scope of the function declaration. If you need to refer to the enum constants outside of a function call, you could use myString::compare::CaseSensitivity. As a convenience, perhaps the name of the type could be omitted and you could use the parameter name here, and "enum" could automatically be a strong enumeration (so you can't use booleans or integers instead of enumeration constants): class myString { int compare( myString, enum { insensitive, sensitive } sensitivity ); Within the function definition, these local types would also be in scope (possibly qualified as "sensitivity::insensitive" if that is preferred). The same idea, with a similar convenience, could give you: class point { point(struct double x, struct double y); point(struct double distance, struct double angle); ... }; This would be a convenience syntax for: class point { struct point_x { double x }; struct point_y { double y }; struct point_distance { double distance }; struct point_angle { double angle }; point(point_x x, point_y y); point(point_distance distance, point_angle angle); ... }; auto p = point(.x = 1, .y = 2); would be auto p = point(point_x(1), point_y(2)); This would give you all you need for overloading based on named parameters, within the existing type system - no changes are needed in name mangling or anything else. It's just a little short-cut for using strong types for parameter names. (I'm sure the syntax and details, especially scoping, will need more careful thought than I've given it here.) > > > Fourth: // warning, marketing regularly changes the default value of > this function void foo(double a = 1234.5, int b = 6789); > > foo(b:=1234); > > This won't compile in C++17. However it seems like it would be useful > to not clutter function calls with default parameters that you don't > care about. In the case I gave it is a maintenance problem to update > all uses of foo every time the defaults change, though I'm not sure > if this is actually a common problem. > -- 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/pl6ob7%249k1%241%40blaine.gmane.org. .