220 40016 <1535202042.894777.1485823136.142315CB@webmail.messagingengine.com> article Path: news.gmane.org!.POSTED!not-for-mail From: Henry Miller Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Named parameter requirements Date: Sat, 25 Aug 2018 08:00:42 -0500 Lines: 418 Approved: news@gmane.org Message-ID: <1535202042.894777.1485823136.142315CB@webmail.messagingengine.com> References: <1535143590.2866704.1485082464.62271AE8@webmail.messagingengine.com> <391e060e-a7eb-48b0-9646-38d6e8bad6ff@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_----------=_15352020428947770" Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1535201927 12533 195.159.176.226 (25 Aug 2018 12:58:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 25 Aug 2018 12:58:47 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDQPBM7KRMDBB7FFQXOAKGQE7JNMRWA@isocpp.org Sat Aug 25 14:58:43 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qt0-f200.google.com ([209.85.216.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ftY9E-0002u1-00 for gclcip-std-proposals@m.gmane.org; Sat, 25 Aug 2018 14:58:36 +0200 Original-Received: by mail-qt0-f200.google.com with SMTP id z44-v6sf10733347qtg.5 for ; Sat, 25 Aug 2018 06:00:46 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1535202045; cv=pass; d=google.com; s=arc-20160816; b=cWt+4MqLZmOJ+ehuMKemTBVN6coy0P6CmqF0Mf1KzXeJN3NXPDD7oInMNsXUPlSap6 Aom109L5mg+vJsTvxVPZFagL9QkLHrLzUwTEX4BIVVsOrdp1aKeFoZVVR0YClDoqaoDA 7crGSKI5XBrIPXuaEATU6VkX5Q8Q08un7OP8G140Vx3WNFIUQ42LM7SotV/cgzbJ5usy ruelmIPNTATUDmFkm40pnI51di/gPdvQZu698nfap4Ywb+quBXQc+5MrvP3ezHFbAZhK BWYU+Bt/KBpgX19GwbIu98AOi9FQhCeoIlBOYnaMnuaIBou3ZI0LSeQYWVB+l6uCWGnW aXvQ== 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:date:subject:references :in-reply-to:content-transfer-encoding:mime-version:to:from :message-id:arc-authentication-results:arc-message-signature :dkim-signature:arc-authentication-results; bh=+J0qmqE9TRZziZcp2+NLM8hW994MyqNKwAOaaAfJMjk=; b=lPE9tCHdHR56PnQ7A2VSs5dixrHBUaDf7hTGDeI74AdG+9OVmRVPort81YxVk8A6Gz 9aHboZbqn4oUZxfayr3GPUmz6lCGHdS94j4qSUaN9g7Niqz0yckom4oAUrg0yq+EKr2T /x2/QllHKfMBDU+OwRP01krN0Hz9CS4rJPQQXnXEwGa0hTqlf6a/LNBNaRgkO+WmE+6F tu75ORG+Kgtma9EOqZi0rItHz0bcH/JD/4+dabVARZuGpnGJmrCGbOsrtLbeDec+h5yc FkmT8xPfoLEvYalzP28jTYUuDgHhPqCUHJiy836rf+6jAwD6b2JhukjDI1BJrIT1Z6Rp nZVw== ARC-Authentication-Results: i=2; mx.google.com; dkim=temperror (no key for signature) header.i=@millerfarm.com header.s=mesmtp header.b=KYvcrSei; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=uNAxyiFj; spf=pass (google.com: domain of hank@millerfarm.com designates 66.111.4.25 as permitted sender) smtp.mailfrom=hank@millerfarm.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=message-id:from:to:mime-version:content-transfer-encoding :in-reply-to:references:subject:date: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=+J0qmqE9TRZziZcp2+NLM8hW994MyqNKwAOaaAfJMjk=; b=uyAXrK7zMxdalMdR7oL9aSf2eGa42KUO0l9elwLKN3dv3MnsI5KHGwpGPFz//NInqK z7nfv19rmhqkaYqvTbkFJsb5Ie4srBWbFaD4rG3Pb3AKB8UmNLXaqvW1opfiQE2xDRHi wi4JWEP9m+avxCYwK7SQDiRJ0EK7uLMUjoEnTlhEe7fDpLenaWOnNif0+6qTBrbqz3Ov 9IhLyOQrsTVFiLxWsb4quWpzybXOiAGHjNfAFS0QrZdGnPWwrKgbclXFnVMZIgHT5Cb4 SK29+rstGGONrqP58BT+Z4n8CbVqeOfxIIXeqLrFnEOLsuh51XfvN43ucMCds71X1owa zIHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:to:mime-version :content-transfer-encoding:in-reply-to:references:subject:date :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=+J0qmqE9TRZziZcp2+NLM8hW994MyqNKwAOaaAfJMjk=; b=jsxuR0kmxHyU/skqsUTgPaXyoHnACB/nwye2XkfgB025lWPMXyG5xU4xL01juZft0N fbWhzCWNjG+fuMG/apY9lYZ5LFu8hdKQBX8Oua901AqVDk07uk9otgjXKS3ams+j1an9 309W3K7De2d/iNmVebQ02epl+uoiNBO8UYy9GkPCvDKcPcLu+4Bjdfx6cEqFXtIDYF4d CRlZCrIYBkKPRdR8drB0vxrbENYw63ZAN8mg3FwYj5ae8X/MM8T0D75hEwYFV41kasVx NvHQhK9Jji5vJt+2mqEmgur8PKSFoYRD1I1IcSnpsqqUoz/MOaRVVXC2tpZVaClStbSq tN0 X-Gm-Message-State: APzg51DUxpmv8nCzES2phHZspD3xnGhW0K8qIDBYymzxpdCvt3A/CF6s NnvfjRHjc4esslHETqVJgOwvBA== X-Google-Smtp-Source: ANB0VdaG5BplWZoYsv+C/BsyP05Pwgc7eB/FOSY3xbYwu/D1rMVbXh1/N5hK5xyYuNxLsxqzPyiQ7A== X-Received: by 2002:a0c:ad09:: with SMTP id u9-v6mr3345984qvc.29.1535202045822; Sat, 25 Aug 2018 06:00:45 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:aed:3c72:: with SMTP id u47-v6ls2753476qte.6.gmail; Sat, 25 Aug 2018 06:00:44 -0700 (PDT) X-Received: by 2002:ac8:225d:: with SMTP id p29-v6mr6085021qtp.57.1535202044639; Sat, 25 Aug 2018 06:00:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535202044; cv=none; d=google.com; s=arc-20160816; b=ZCVTe2Hk0Xg/03Kmu1C4LQ1xpXZDjkqX5MlJRgOktPSKJcQf0vjVOKItPC0LSTklos oNhmuzX1gz85Ozw1JRAVGsvSwPtjdrhMLBTP+Kwn+xA0WENZ3BQJXp5IUtrgSAssw5TZ Gz3HfnmuVrcP0xzj+RpMBIgeZwG27Mp8UzxHSxG6umfMH4KvFaDgzwhn6kHa0a5TxEDg F54kUsgz2wfKlyh9pHwIZy1+Oa7f5i/Po8W06kmvChqngjQX0kqVaFjMjg+NzxjlqmGO LXROWLH+JzDz5pIDgig7spAQI46zW6zaDMQcyddE5sO7FFNHNsPRS3bcDmrNBYwK0g5m PsBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=date:subject:references:in-reply-to:content-transfer-encoding :mime-version:to:from:message-id:dkim-signature:dkim-signature :arc-authentication-results; bh=Ny+BOvrTBN3c67yUt6Yfszqorg/7pgjugXS900+4wI8=; b=C8CGmHS7HKBVODp0qDlyIsiEiHhrHGllwyStwL+e8521bu4JU6+/ItovDwRxTHgUk1 5eI2bprC0jW94jEXk+42OcZMQgYgNNGPBXiyjsN0XgPg+fW2oExztJCN0FxqbCnEWLE8 i7buVETa1BarXJ7hkVk8d34FttgQD+5OHzmiovDqZJaB882A+FsTtV3PvgQyNpmKXGNz s3O2BpJMYFEbsp9XYfFnzUizbWNSQmba6UFlpaaUiW2Us6PHUNQMvDLiYAjst7tWXhCt Zpw/nSrB2uu9S0Jpw9LGBJzPvOyogy96JRVDBfsI7fjeIkbpVchrLZ6fWZhCOZp56q8h 2TVg== ARC-Authentication-Results: i=1; mx.google.com; dkim=temperror (no key for signature) header.i=@millerfarm.com header.s=mesmtp header.b=KYvcrSei; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=uNAxyiFj; spf=pass (google.com: domain of hank@millerfarm.com designates 66.111.4.25 as permitted sender) smtp.mailfrom=hank@millerfarm.com Original-Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com. [66.111.4.25]) by mx.google.com with ESMTPS id s43-v6si3455626qtk.382.2018.08.25.06.00.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Aug 2018 06:00:44 -0700 (PDT) Received-SPF: pass (google.com: domain of hank@millerfarm.com designates 66.111.4.25 as permitted sender) client-ip=66.111.4.25; Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 30B2721E06 for ; Sat, 25 Aug 2018 09:00:42 -0400 (EDT) Original-Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Sat, 25 Aug 2018 09:00:43 -0400 X-ME-Proxy: X-ME-Sender: Original-Received: by mailuser.nyi.internal (Postfix, from userid 99) id 367A79E50D; Sat, 25 Aug 2018 09:00:42 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface - ajax-7b72137a In-Reply-To: <391e060e-a7eb-48b0-9646-38d6e8bad6ff@isocpp.org> X-Original-Sender: hank@millerfarm.com X-Original-Authentication-Results: mx.google.com; dkim=temperror (no key for signature) header.i=@millerfarm.com header.s=mesmtp header.b=KYvcrSei; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=uNAxyiFj; spf=pass (google.com: domain of hank@millerfarm.com designates 66.111.4.25 as permitted sender) smtp.mailfrom=hank@millerfarm.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:40016 Archived-At: This is a multi-part message in MIME format. --_----------=_15352020428947770 Content-Type: text/plain; charset="UTF-8" On Sat, Aug 25, 2018, at 3:22 AM, mihailnajdenov@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[1]?> 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. >> >> 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")) >> >> >> 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[2]. Links: 1. http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/1991/WG21%201991/X3J16_91-0127%20WG21_N0060.pdf 2. https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/391e060e-a7eb-48b0-9646-38d6e8bad6ff%40isocpp.org?utm_medium=email&utm_source=footer -- 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/1535202042.894777.1485823136.142315CB%40webmail.messagingengine.com. --_----------=_15352020428947770 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8"


On Sat, Aug 25, 2018, at 3:22 AM, mihailnajdenov@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 nam= ed 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 i= n 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 corre= ct 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 go= t the parameters right because the compiler won't tell you. This is undesir= able, people often write unsafe code just because the alternatives are perc= eived 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 t= he 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 compatibil= ity 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) =3D 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 n= eed to know rows and columns. Woe to the programmer who mixes them up (it w= on't crash but it can give incorrect results). We would like to be compatib= le with them for these functions if they will accept any proposal. 


<= br>
Not change ABI. This is controversial. Th= ere 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 proposa= l that changes ABI will face a larger battle and need stronger justificatio= n.

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

Support future expansion. There are a num= ber of different ideas out there solving semi-disjoint problems. Whatever i= s done first will not be last. Do our best to not lock out the ideas that o= ther people care about that you do not care about.

Existing code needs to still build and wo= rk. Of course if the existing  code is actually wrong and nobody notic= ed 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 s= ometimes 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 compl= ex 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" F= or example, in python syntax AddGraphPoint(x=3DEmployeeId, y=3Dincome) - em= ployeeID is a great variable name in general, but it generally isn't someth= ing you normally graph, at least we know it is intentional.

The second problem is when writing code i= t is easy to mix up the order of identical typed parameters. It would be ni= ce if matrix.GetCell(row, column) would tell me if it should be matrix.GetC= ell(column, row).

The third problem is  GUI windows of= ten have a large number of things the user can set on creation, and typical= ly 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 te= nd to be inefficient. Sometimes the inefficiency is runtime, sometimes it i= s 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-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, 
so had to look the documentation (online, because I don't have = it locally). Turned out there is a warning static function. One m= ight 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>
 
I don't understand the probl= em. 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} <= /span>

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

<= br>

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


There are some who argue that we can alre= ady 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 The= Integer;};   This starts looking fine, but to be really useful this ne= eds to implement all the operators.  When you finally break down and d= o that you discover you also have to overload everything in <cmath> s= o you can get std::abs working - users are not allowed to extend the std na= mespace, but we need to break this rule if our new type is to work.  B= efore you propose fixing this, remember that Meter::operator* returns a Squ= areMeter 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 s= uccessful 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 s= trong 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 ar= e subscribed to the Google Groups "ISO C++ Standard - Future Proposals" gro= up.
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.
<= /div>

--
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 http= s://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1535202042.894777.= 1485823136.142315CB%40webmail.messagingengine.com.
--_----------=_15352020428947770-- .