220 40017 <57934e52-1e0b-4fdb-9cb9-894eb3c7cc07@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: mihailnajdenov@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Named parameter requirements Date: Sat, 25 Aug 2018 06:53:39 -0700 (PDT) Lines: 534 Approved: news@gmane.org Message-ID: <57934e52-1e0b-4fdb-9cb9-894eb3c7cc07@isocpp.org> References: <1535143590.2866704.1485082464.62271AE8@webmail.messagingengine.com> <391e060e-a7eb-48b0-9646-38d6e8bad6ff@isocpp.org> <1535202042.894777.1485823136.142315CB@webmail.messagingengine.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_533_96660702.1535205219827" X-Trace: blaine.gmane.org 1535205099 20935 195.159.176.226 (25 Aug 2018 13:51:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 25 Aug 2018 13:51:39 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBZF6QXOAKGQEUZTH4OI@isocpp.org Sat Aug 25 15:51:35 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 1ftYyR-0005F1-QY for gclcip-std-proposals@m.gmane.org; Sat, 25 Aug 2018 15:51:32 +0200 Original-Received: by mail-yb0-f198.google.com with SMTP id l206-v6sf6575081ybl.23 for ; Sat, 25 Aug 2018 06:53:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to: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=75nnbEM0wAnjCq8L69o0nDGTLmFpfZ3al6YUcZUnbvQ=; b=COrcwAfTgpPmvzsE6JYSY3XHRHGzDnMvFs1n9UXBeBi2DoZgbkOyfbySzlyjDthm77 HVhfOstdEoZNCiVuzt30HV4WtKUN44RFn/F0lFllykoxh4WXbN7J3cBcIqsplJKKrwEU TmDK5ML/EdLLNM2o3a8sVfrnDcaxtmOvVbEzDex3ZNxqQK9dGqUggb/4YCDXwXXKbKit KhbPDFHxSZ74tmv2/xLaW2vc9F7iE8qJ98eTWWfX8y4f9TNqz5GAmUeJ8wkOExTFNGLl 5WRQgbasxrh3M+IUpeAiChFuYhZ8tJ5T7Hj82lpNDq3gYz1wb7M1wtqbOsO6aXQ1jQy1 Xndw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to: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=75nnbEM0wAnjCq8L69o0nDGTLmFpfZ3al6YUcZUnbvQ=; b=LE0J2QXfDLttoNhFd7jBXh6l6w9DXPrZLEVzD3Aoo82Xd2UDh3StwuZv5wVneA50IM /y40QahwmFI2XXacuBCCOUbbuYlw1HSscQoiIFp/NYON4U9F6yiQOM6oSMIDrVlrUpdf xDWtNcMFEu17X9YV8yBzOjofq4OSbKFmCGcMwRsyjavfLrsoH0KxJHDPTGiaafPfExFM 3GzYBu8q6a2HzojQkZGIuX7IGELVuxtJrwdNGQO9UZcQ1O+5TFm1Ws/om1J3uXgGGPiE OIkbQsSFFo41fINw9g1cCWMSXtmwj4lYQNsQk+2u1vtTFabuxtPVP7S2oh4RCT7fro71 WEfw== 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: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=75nnbEM0wAnjCq8L69o0nDGTLmFpfZ3al6YUcZUnbvQ=; b=iemZ4Z9QU7+dhojSu4eBHvqjjS/3gZUaeyJ2DquAGe556DAiBVeqV0szOASz4Jw9Pp vzZjFgCvAPBpNu57wbgQhvdVrkdB3B5aVRefip+bE1QA9hT6aG2P9FJ/Vv79XvE+YGui zFCx0spNqDWJjfy0+BLW2iWGktEeLuc8d67B9JqmylBe1+a2z4xfW2VEvngOfG2UdmTf 7DXQZWzmK9nqC5JEJZeIr1g2NIXNPKlyzDVvHiTrbf/SC4Lq4nQ6MDTkY2MkeWy85Zmz 5b5HO30qNEYmIL4mGWBkwuqEaZlxldfKitj3rT32FO5OTSdkAAHhynABkBFmj632YXAF oKxg== X-Gm-Message-State: APzg51DvC3SZgnfTv9KlpMc7hVfcubaa9yVtSL4xv2loBCKt47hg3tL5 RMjBVXzb++WxMDxyb62MGbdH2A== X-Google-Smtp-Source: ANB0VdZ9yha+Tt8xSFyWsU8YUmiOzbVOqZzMiU6IGmXx+b+Sxyqhh+luD9NYBtnzlrEPKf/TU9u87A== X-Received: by 2002:a5b:746:: with SMTP id s6-v6mr1766247ybq.65.1535205221661; Sat, 25 Aug 2018 06:53:41 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a0d:d50a:: with SMTP id x10-v6ls939256ywd.13.gmail; Sat, 25 Aug 2018 06:53:40 -0700 (PDT) X-Received: by 2002:a0d:ed04:: with SMTP id w4-v6mr77912ywe.1.1535205220278; Sat, 25 Aug 2018 06:53:40 -0700 (PDT) In-Reply-To: <1535202042.894777.1485823136.142315CB@webmail.messagingengine.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:40017 Archived-At: ------=_Part_533_96660702.1535205219827 Content-Type: multipart/alternative; boundary="----=_Part_534_355403563.1535205219828" ------=_Part_534_355403563.1535205219828 Content-Type: text/plain; charset="UTF-8" On Saturday, August 25, 2018 at 4:00:46 PM UTC+3, Henry Miller wrote: > > > > On Sat, Aug 25, 2018, at 3:22 AM, mihailn...@gmail.com > wrote: > > > > On Friday, August 24, 2018 at 11:46:32 PM UTC+3, Henry Miller wrote: > > > As a followup to my previous email on named parameters, I've collected as > best I can what I think everybody actually wants. This is round one of > requirements - there are some that are in conflict with others. There are > others than strongly desired by some and strongly opposed by others. > > The high level problem statement we want to make writing AND maintaining > correct code easier. We can all write correct code today; but there are > times where you either have to write a lot of boilerplate code, write code > with a nasty syntax, or just trust that you got the parameters right > because the compiler won't tell you. This is undesirable, people often > write unsafe code just because the alternatives are perceived as too > difficult/too ugly. > > goals: > > > > Have C support the syntax as well. While C++ has a lot of things that C > cannot do, interoperability with C is a very strong selling point of C++. > Thus a proposal that is accepted by WG14 at the same time is desired. The > C++ version will likely be more complex to handle things in C++ that don't > exist in C, but we would like compatibility for the parts that are common > with C. > > > What does this mean? Does it mean we are still at "reuse arguments as > names", 1991 style > > ? > Or, because no ABI break we can use macros if we are compiling for C, like > we do today with default values: > #ifdef __cplusplus > #define FI_DEFAULT(x) = x > #else > #define FI_DEFAULT(x) > > > > C has the same problem we have. Consider this c function > Manipulate2dArray(int array*, int numRows, int numColumns); > > I no longer remember what the typical way to pass a 2 dimensional array of > arbitrary size is, but in some way they need to know rows and columns. Woe > to the programmer who mixes them up (it won't crash but it can give > incorrect results). We would like to be compatible with them for these > functions if they will accept any proposal. > If we are talking just for C++, one can always wrap the call, using better types and/or names. The requirement to work with C is a feature creep, that ultimately does not suit many (library authors), and, as said, has already failed. > > > > Not change ABI. This is controversial. There are some things people would > like to do that require ABI changes. These are not necessarily bad ideas, > and may be worth doing. However any proposal that changes ABI will face a > larger battle and need stronger justification. > > Do things that cannot be done with the type system. There are many people > who consider c++ a strongly typed language, they consider most proposals a > work around for cases where the type system is too weak. > > Support future expansion. There are a number of different ideas out there > solving semi-disjoint problems. Whatever is done first will not be last. Do > our best to not lock out the ideas that other people care about that you do > not care about. > > Existing code needs to still build and work. Of course if the existing > code is actually wrong and nobody noticed before it would be nice if it > fails to build; but assuming no bugs, code that builds today needs to build > tomorrow. > > Work with all existing parts of C++. If sometimes the user gets an error > from what looks like the same syntax of the last function call just because > this one happens to use a dark corner of C++, that is undesired. > > Not sink the Vasa. C++ is already a complex language, all additions will > be looked on with suspicion. The gain needs to justify the costs. > > > > > Problems we want to fix. These can be separate proposals, but if so they > need to allow the others > > The first problem we want to fix is the "why did the previous maintainer > call that function with those parameters" For example, in python syntax > AddGraphPoint(x=EmployeeId, y=income) - employeeID is a great variable name > in general, but it generally isn't something you normally graph, at least > we know it is intentional. > > The second problem is when writing code it is easy to mix up the order of > identical typed parameters. It would be nice if matrix.GetCell(row, column) > would tell me if it should be matrix.GetCell(column, row). > > The third problem is GUI windows often have a large number of things the > user can set on creation, and typically the user will accept the defaults > for 90%, but it is a different set of parameters where the default is wrong > for each user. The current options tend to be inefficient. Sometimes the > inefficiency is runtime, sometimes it is compile time, and sometimes it is > human typing/reading time, but all are inefficient. > > > Forth problem people want fixed is the named constructor problem. For this > we need strong names, but it is valid request never the less. > > Just yesterday spend 5 minutes looking how to create a QMessageBox that > shows a warning-styled ready dialog: the constructor did not help as it is > an all-in-one one, could not find any suitable get* static function, > so had to look the documentation (*online*, because I don't have it > locally). Turned out there is a warning static function. One might argue, > "it is all clear", but is it. > > Note that that exact problem could not be solved gracefully by types > either, tags might be ok, but as always they will fight for naming and > scoping - where to put them, how to name them to be clear what is going on. > > > I don't understand the problem. The static function controls lifetime and > returns a value, both things that a constructor cannot do. > > What is the problem that cannot be solved with an enum? Enum class > messagetype { about, critical, information, warning} > > Or with types > MessageBox(warningText("ut oh")) > With enums the implementation is affected considerably - one will have to use switch and dispatch to helper functions to do construction. Also, not all types of ready-made dialogs have the same params - 'about' does not take buttons. Types don't scale all that well. Also, they will untimely be confusing to the user when he sees them, they will have to be documented as "only here because overloading, nothings special, really". That is the problem with introducing types with no meaning of its own and probably that is why it is not a common practice. None of the solutions are bad, honestly, but they are only as good as a workaround goes, and quite a few people want that improved with names. > > > > > For the second problem there are some who would like the compiler to > reorder the call to just do the right thing. Defining the rules for when > this can happen is probably easy, but I would suggest that we first get the > above working before thinking about this. Real world experience one a small > change can drive this latter. > > > There are some who argue that we can already do the first two with the > existing c++98 code. While technically true, they all sink the Vasa in real > world code. Sure the c++ standard is small, but there is a lot of extra, > and subjectively ugly code required to make it work. > > For example > > struct ICannotBeliveItIsNotAnInt {int TheInteger;}; This starts looking > fine, but to be really useful this needs to implement all the operators. > When you finally break down and do that you discover you also have to > overload everything in so you can get std::abs working - users are > not allowed to extend the std namespace, but we need to break this rule if > our new type is to work. Before you propose fixing this, remember that > Meter::operator* returns a SquareMeter not a meter. > > This isn't to say that you cannot expand strong types to fix the above, > but if you want to do that you need to write your own proposal. > > > > So what do you think, did I get a reasonably balanced view of what people > want and what is painful enough that it is worth considering? Is it worth > going farther? This could be turned into a proposal to the EWG, which if > successful will give everyone who has a specific syntax in mind a direction > to focus their efforts (either just write the proposal, or come up with a > strong argument why something everyone thinks we need is worth sacrificing) > > > I think it is the correct approach, focusing on requirements, leaving > syntax and implementation flavors aside for now. > > > -- > 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-proposal...@isocpp.org . > To post to this group, send email to std-pr...@isocpp.org . > To view this discussion on the web visit > https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/391e060e-a7eb-48b0-9646-38d6e8bad6ff%40isocpp.org > > . > > -- 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/57934e52-1e0b-4fdb-9cb9-894eb3c7cc07%40isocpp.org. ------=_Part_534_355403563.1535205219828 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Saturday, August 25, 2018 at 4:00:46 PM UTC+3, = Henry Miller wrote:


On Sat, Aug 25, 2018, at 3:22 AM, mihailn...@gmail.com wrote:


On Friday, August 24, 2018 at 11:46:32 PM = UTC+3, Henry Miller wrote:

=
As a followup to my previous email on name= d parameters, I've collected as best I can what I think everybody actua= lly wants. =C2=A0This is round one of requirements - there are some that ar= e in conflict with others. There are others than strongly desired by some a= nd strongly opposed by others.

The high level problem statement we want t= o make writing AND maintaining correct code easier. We can all write correc= t code today; but there are times where you either have to write a lot of b= oilerplate code, write code with a nasty syntax, or just trust that you got= the parameters right because the compiler won't tell you. This is unde= sirable, people often write unsafe code just because the alternatives are p= erceived as too difficult/too ugly.

goals:
=C2=A0

Have C support the syntax as well. While C= ++ has a lot of things that C cannot do, interoperability with C is a very = strong selling point of C++. Thus a proposal that is accepted by WG14 at th= e same time is desired. =C2=A0The C++ version will likely be more complex t= o handle things in C++ that don't exist in C, but we would like compati= bility for the parts that are common with C.

What does this mean? Does it mean we are still at "reuse argument= s as names", 1991 style?=C2=A0
Or, because no ABI break we can use macros if we are compiling for C, = like we do today with default values:
#ifdef _= _cplusplus=C2=A0
#define = FI_DEFAULT(x) =3D x
#else
#define FI_DEFAULT(x)
=C2=A0

C has the same problem we have. Consider t= his c function=C2=A0
Manipulate2dArray(int array*, int numRows,= int numColumns);=C2=A0

I no longer remember what the typical way = to pass a 2 dimensional array of arbitrary size is, but in some way they ne= ed to know rows and columns. Woe to the programmer who mixes them up (it wo= n't crash but it can give incorrect results). We would like to be compa= tible with them for these functions if they will accept any proposal.=C2=A0=

If we are talking just for C++= , one can always wrap the call, using better types and/or names.=C2=A0
The requirement to work with C is a feature creep, that ultimately do= es not suit many (library authors), and, as said, has already failed.=C2=A0=
=C2=A0



Not change ABI. This is controversial. The= re are some things people would like to do that require ABI changes. These = are not necessarily bad ideas, and may be worth doing. However any proposal= that changes ABI will face a larger battle and need stronger justification= ..

Do things that cannot be done with the typ= e system. There are many people who consider c++ a strongly typed language,= they consider most proposals a work around for cases where the type system= is too weak.

Support future expansion. There are a numb= er of different ideas out there solving semi-disjoint problems. Whatever is= done first will not be last. Do our best to not lock out the ideas that ot= her people care about that you do not care about.

Existing code needs to still build and wor= k. Of course if the existing =C2=A0code is actually wrong and nobody notice= d before it would be nice if it fails to build; but assuming no bugs, code = that builds today needs to build tomorrow.

Work with all existing parts of C++. If so= metimes the user gets an error from what looks like the same syntax of the = last function call just because this one happens to use a dark corner of C+= +, that is undesired.

Not sink the Vasa. C++ is already a comple= x language, all additions will be looked on with suspicion. The gain needs = to justify the costs.=C2=A0
=C2=A0

=
Problems we want to fix. =C2=A0These can b= e separate proposals, but if so they need to allow the others

The first problem we want to fix is the &q= uot;why did the previous maintainer call that function with those parameter= s" For example, in python syntax AddGraphPoint(x=3DEmployeeId, y=3Dinc= ome) - employeeID is a great variable name in general, but it generally isn= 't something you normally graph, at least we know it is intentional.

The second problem is when writing code it= is easy to mix up the order of identical typed parameters. It would be nic= e if matrix.GetCell(row, column) would tell me if it should be matrix.GetCe= ll(column, row).

The third problem is =C2=A0GUI windows oft= en have a large number of things the user can set on creation, and typicall= y the user will accept the defaults for 90%, but it is a different set of p= arameters where the default is wrong for each user. The current options ten= d to be inefficient. Sometimes the inefficiency is runtime, sometimes it is= compile time, and sometimes it is human typing/reading time, but all are i= nefficient.

Forth problem people want fixed is the named constructor problem. For = this we need strong names, but it is valid request never the less.
Just yesterday= spend 5 minutes looking how to create a QMessageBox that shows a warning-s= tyled ready dialog: the constructor did not help as it is an all-in-one one= , could not find any suitable get* static function,=C2=A0
so had to look the documentation (online, because I don't h= ave it locally). Turned out there is a warning static function. One might argue, = "it is all clear", but is it.

Note that that exact problem could not be solved gracefully by types e= ither, tags might be ok, but as always they will fight for naming and scopi= ng - where to put them, how to name them to be clear what is going on.
<= /div>
=C2=A0
I don't understand the pr= oblem. The static function controls lifetime and returns a value, both thin= gs that a constructor cannot do.=C2=A0

What is the problem that cannot be solved = with an enum?=C2=A0= Enum class messagetype { about, critical, information, warning}=C2=A0

Or with types
MessageBox(warningText("ut oh"))

With enums the implementation is affected= considerably - one will have to use switch and dispatch to helper function= s to do construction.=C2=A0
Also, not all types of ready-made dia= logs have the same params - 'about' does not take buttons.

Types don't scale all that well. Also, they will untim= ely be confusing to the user when he sees them, they will have to be docume= nted as "only here because overloading, nothings special, really"= ..
That is the problem with introducing types with no meaning of i= ts own and probably that is why it is not a common practice.=C2=A0

None of the solutions are bad, honestly, but they are only= as good as a workaround goes, and quite a few people want that improved wi= th names.=C2=A0
=C2=A0




For the second problem there are some who = would like the compiler to reorder the call to just do the right thing. Def= ining the rules for when this can happen is probably easy, but I would sugg= est that we first get the above working before thinking about this. Real wo= rld experience one a small change can drive this latter.


There are some who argue that we can alrea= dy do the first two with the existing c++98 code. While technically true, t= hey all sink the Vasa in real world code. Sure the c++ standard is small, b= ut there is a lot of extra, and subjectively ugly code required to make it = work.

For example

struct ICannotBeliveItIsNotAnInt {int TheI= nteger;}; =C2=A0 This starts looking fine, but to be really useful this nee= ds to implement all the operators. =C2=A0When you finally break down and do= that you discover you also have to overload everything in <cmath> so= you can get std::abs working - users are not allowed to extend the std nam= espace, but we need to break this rule if our new type is to work. =C2=A0Be= fore you propose fixing this, remember that Meter::operator* returns a Squa= reMeter not a meter.

This isn't to say that you cannot expa= nd strong types to fix the above, but if you want to do that you need to wr= ite your own proposal.
=C2=A0
So what do you think, did I get a rea= sonably balanced view of what people want and what is painful enough that i= t is worth considering? =C2=A0Is it worth going farther? This could be turn= ed into a proposal to the EWG, which if successful will give everyone who h= as a specific syntax in mind a direction to focus their efforts (either jus= t write the proposal, or come up with a strong argument why something every= one thinks we need is worth sacrificing)

I think it is the correct approach, focusing on requirements, leaving syntax and implementation flavors aside for now.


--
You received this message because you are= subscribed to the Google Groups "ISO C++ Standard - Future Proposals&= quot; group.
To unsubscribe from this group and stop r= eceiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr.= ...@isocpp.org.

--
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/57934e52-1e0b-4fdb-9cb9-894eb3c7cc07= %40isocpp.org.
------=_Part_534_355403563.1535205219828-- ------=_Part_533_96660702.1535205219827-- .