220 40015 <391e060e-a7eb-48b0-9646-38d6e8bad6ff@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 parameter requirements Date: Sat, 25 Aug 2018 01:22:43 -0700 (PDT) Lines: 323 Approved: news@gmane.org Message-ID: <391e060e-a7eb-48b0-9646-38d6e8bad6ff@isocpp.org> References: <1535143590.2866704.1485082464.62271AE8@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_451_872959918.1535185363947" X-Trace: blaine.gmane.org 1535185242 25594 195.159.176.226 (25 Aug 2018 08:20:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 25 Aug 2018 08:20:42 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBVNDQTOAKGQEOMGWXNI@isocpp.org Sat Aug 25 10:20:38 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f200.google.com ([209.85.213.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ftToC-0006WG-D4 for gclcip-std-proposals@m.gmane.org; Sat, 25 Aug 2018 10:20:36 +0200 Original-Received: by mail-yb0-f200.google.com with SMTP id 198-v6sf6377653ybc.2 for ; Sat, 25 Aug 2018 01:22:46 -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=JE1G+tpoDYN3pzo9MTNnVyqBtPCM+xqX2t22BWxOEAc=; b=c26vnhv/V1fEl5WWlz48kehemO3eumPTyXMffEx8serkEfCI3joxahVaHxQt8gZmMh kWtfLhNK4m5ZZzzsIGCLpxmtRnbjGJRWJQheQDZYW+7fhfOjbgI3AIYzutuwTLLytQVT 985hIcK3OWx1kqGEqjh+5gy0k1x2RGdl/Ij49kuDNhU0FDV5WEKvac4WWvMmcVDaKwyw roCYZUs4dBABAKnxGShyHJIzzGLDEc7tCQO4pH0nHo0Kx/FzczsfG0s3yzggvF7RifgB NHxGxd5GX1L+wP7fzLBAk9ohHzTTpAZvNfjSUswCtawmhlEo1FTF+QBqmmvMQaSUJNtz YaBg== 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=JE1G+tpoDYN3pzo9MTNnVyqBtPCM+xqX2t22BWxOEAc=; b=GdvbccviAnolzGhC3j+386NoEpMTwQuG8dO+zECtjrDHX4kaqRXFR5vL9P97ooyH2Y Awbx2eDcB5125N9rqJLPHtOJK80mus+b8UcRN1HJEgYWQYSjs7YNE1D85+WqvPrUgVqQ HmZG5z/OAoyF/vKwpGHlLn+jcD7K87GkM1acIWjdqNNg26hQYuqmQ5nIVV2JpKfOJdUg g5Xt0/kLSRW/YP8h3/xukmBsvnw5LI27iDgUACftO1PLkd0Y/fAd0kIZOp5WZVMH3wmJ iEUbQCWo+cDO5rBMPqgNGQoz3fyRu+/2HmMVfduMhss0zJYxbltLQkoAR9UetSD0NAV1 1CKw== 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=JE1G+tpoDYN3pzo9MTNnVyqBtPCM+xqX2t22BWxOEAc=; b=cRYc9O+4cIJ69yHnNcoKoSCVINct16R4vXjWG1P3+ccNf0amLAgBLViBSQ5Xp8qx6w omSutu0K9l1KsemLyn1VtPAOfpMYUPjO97ARFayj0TlMnkp8RfkJyHqWAE5hsjZTtMmB phGQpXgjHqToPSw5C0Nnn2VGO8226NuaIEcNqDSK4G3tRFFpPw1VgCBhut7wD3saYqVq axVDmHVYKXHAsFYY0u48JVJeVbIiDAnQ6bsmvOvh/mzKC/NtlTsxLoYR2eC+zGOr1ktM 8drxHdq3yCuBpYNeuxOn1j2tqt9fGYbTZHpJTEGUChHlT8+sYiUDGG/gInqkzqmhCSNa oVdw== X-Gm-Message-State: APzg51B6XC9mxtxoEGxdDkJReXkH2VIM6TOwHdimDjPgTTO18QW8sn7M UKRZhOshEi24LZeh1UF1aHJ5MQ== X-Google-Smtp-Source: ANB0VdYan5X3XZNrohSq+XFyDra+Gw+Gt91wA9eQ0hJzv7ym9mHnLz5W0Vmbf5EewFX4017j8d2MXA== X-Received: by 2002:a0d:ec90:: with SMTP id v138-v6mr1652505ywe.67.1535185366412; Sat, 25 Aug 2018 01:22:46 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:2107:: with SMTP id h7-v6ls2012168ybh.17.gmail; Sat, 25 Aug 2018 01:22:44 -0700 (PDT) X-Received: by 2002:a25:ccc9:: with SMTP id l192-v6mr55405ybf.6.1535185364711; Sat, 25 Aug 2018 01:22:44 -0700 (PDT) In-Reply-To: <1535143590.2866704.1485082464.62271AE8@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:40015 Archived-At: ------=_Part_451_872959918.1535185363947 Content-Type: multipart/alternative; boundary="----=_Part_452_33677697.1535185363948" ------=_Part_452_33677697.1535185363948 Content-Type: text/plain; charset="UTF-8" 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) > > 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. > > > 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-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/391e060e-a7eb-48b0-9646-38d6e8bad6ff%40isocpp.org. ------=_Part_452_33677697.1535185363948 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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

As a followup to my previous email on named parameters, I've collec= ted as best I can what I think everybody actually wants. =C2=A0This is roun= d one of requirements - there are some that are in conflict with others. Th= ere are others than strongly desired by some and strongly opposed by others= ..

The high level problem statement we want to make writing AND maintainin= g correct code easier. We can all write correct code today; but there are t= imes where you either have to write a lot of boilerplate code, write code w= ith 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 u= nsafe 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. =C2= =A0The 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 a= re common with C.

What does this mean? Does it mean we a= re still at "reuse arguments 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_DEFAUL= T(x) =3D x
#else
#define FI_DEFAULT(x)
=C2=A0

Not change ABI. This is controversial. There are some things people wou= ld 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 peop= le who consider c++ a strongly typed language, they consider most proposals= a work around for cases where the type system is too weak.=20

Support future expansion. There are a number of different ideas out the= re 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 yo= u do not care about.

Existing code needs to still build and work. Of course if the existing = =C2=A0code 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 bu= ild tomorrow.

Work with all existing parts of C++. If sometimes the user gets an erro= r from what looks like the same syntax of the last function call just becau= se 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 wil= l be looked on with suspicion. The gain needs to justify the costs.=C2=A0
=C2=A0
warning static function. One mi= ght argue, "it is all clear", but is it.

Note that that exact problem could not be solved gracefully by types eithe= r, 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.=C2=A0


For the second problem there are some who would like the compiler to re= order 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 abo= ve working before thinking about this. Real world experience one a small ch= ange 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, a= nd subjectively ugly code required to make it work.

For example

struct ICannotBeliveItIsNotAnInt {int TheInteger;}; =C2=A0 This starts = looking fine, but to be really useful this needs to implement all the opera= tors. =C2=A0When you finally break down and do that you discover you also h= ave to overload everything in <cmath> 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. =C2=A0Before you propose fixing this,= remember that Meter::operator* returns a SquareMeter not a meter.=20

This isn't to say that you cannot expand strong types to fix the ab= ove, but if you want to do that you need to write your own proposal.

=C2=A0
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? =C2=A0= 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 sa= crificing)

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

--
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/391e060e-a7eb-48b0-9646-38d6e8bad6ff= %40isocpp.org.
------=_Part_452_33677697.1535185363948-- ------=_Part_451_872959918.1535185363947-- .