220 36516 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: operator[](...) Date: Sat, 6 Jan 2018 09:57:25 -0800 (PST) Lines: 193 Approved: news@gmane.org Message-ID: References: <8bbeac1f-f698-4e49-9e1f-4cb1ab389b09@isocpp.org> <3b13beef-4a63-1315-c11d-07ba04e6f9bd@gmail.com> <4d35c71c-cdc0-45de-976e-2f70b20695c0@isocpp.org> <5a504df3-7632-4035-9f94-7c72f0d094af@isocpp.org> <35b73d9f-8920-4282-927e-7c2f06c2b49c@isocpp.org> <4ab0ef05-5d80-441d-905e-7d25b53f7379@isocpp.org> <86c40631-4189-4c9c-b664-b2f27dde53b6@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_8928_880883753.1515261445431" X-Trace: blaine.gmane.org 1515261338 9895 195.159.176.226 (6 Jan 2018 17:55:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 6 Jan 2018 17:55:38 +0000 (UTC) Cc: schreiber.corentin@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBBU4YTJAKGQEERSAMYA@isocpp.org Sat Jan 06 18:55:34 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f69.google.com ([209.85.213.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eXsgo-0001rP-FQ for gclcip-std-proposals@m.gmane.org; Sat, 06 Jan 2018 18:55:26 +0100 Original-Received: by mail-vk0-f69.google.com with SMTP id b205sf4593384vke.20 for ; Sat, 06 Jan 2018 09:57:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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=WYB7lCjTKaU3Q3pVdFdiFEk+C/avNSSaACadg7H+bFI=; b=D1FIx24iFRQHULBaogrsb5HYbmE0AZBwzdgCSlUYw/oOcD8ILlAPBlC8J3B1F7xOBB 5FIozSVsheOnlSEwRBOPyVGVIiHQPO9fKIo0XHRWzJfy+TxSZjYtvZVRrYYS3dYYaQpo 9mHuc1nebebqCSqm5QasxEBaIA4YJ0aq8sjMH8U3bdqOtEbI1pJ3F1QvIvVgFzUa8+Cg 4SOPxfmXH2hziCBePDODg0fzz2RD3H72qWpWpi/lce1+NbLo4ka9+F0C3FwnEvvv/JCa /QPOT9ICRqvLi2CUol4hNGe24/GDSMytuP5Jwkg3Ou+8/gpsavCJEkQRaCLAI8ibORe+ fyzg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc: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=WYB7lCjTKaU3Q3pVdFdiFEk+C/avNSSaACadg7H+bFI=; b=bS9ey0PCq6YsQP6iqXbIq/vOlzT/sU002lNQIfqSf9l9qWJVo5kyK1iZUqwvQE4a/5 1PPxbXTTv0eZqe55635Nda2LF8jO08cMG8cKmPunk0j3UW2DeRin28u6eeHu1AMTbESw tHZMAclkzuAvXvUfmxtjeLtD9BDGGuz7FQ8ZiXjlwYiTXVj2zT9Ojw09QvIDLyXjLTGd kwf/K025+6v1LG8gtB3Zsf4B0Ajcz0y50cyr+3h/1Z46UhZT4wGjbqtm85Bpv75cqHKi XdBsQgDpTU5Rco2tv/3r46UbVbFmdWd8d4rDvDrvuP06PWFfmhpuKBPKsXJSNjqDIWXN wgdg== 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:cc: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=WYB7lCjTKaU3Q3pVdFdiFEk+C/avNSSaACadg7H+bFI=; b=D8L+BC2srfvFvdJwHv1EcFLqQ9EVo/BXDyVrqhoAttHTbi1X8Bc5Bc2+I1hzOsfW9G DHwHOh9zULGT8pagcr6mz4E3O8vVBCzXId4RoKWR6TLOWlqrk1jXx0fihBul9cmo3eSa /zJjJU4Y4L+1CzF2c5Snjumb1MMtAOYR7VNiU5MZwPuJKWtBiovQl6Pyb0VXl6IxfXKb Mrl9Eyie1jMhb47XlT3LSGuJZIDpfzLBRTyjRnXWzzGl0KOLlguI/hH7oC+7CrQ6JPTI 9e8F/2nHb/AM/a3yhBeHoQiMuK4zWPv7jBK+gkyKiGoXDO2hq4N8A9t6VBxFZX1mpTqg sgbg== X-Gm-Message-State: AKwxytfOZPVGSpISUhBEsbkzX+f3IpNLEscEBJ1eBHTaNldSMFgubjEg cCvU1DQVIF0vPM8xvZ13Sb7DSg== X-Google-Smtp-Source: ACJfBovjBpVjbJxeo9ta1Awl8SnWCx4+qWObbHCx6Hv0bMtGhQRi0PXXUkE6tPVkDwg/UXS0zZb1ng== X-Received: by 10.176.23.16 with SMTP id j16mr3292819uaf.1.1515261447901; Sat, 06 Jan 2018 09:57:27 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.47.74 with SMTP id v71ls1670171vkv.4.gmail; Sat, 06 Jan 2018 09:57:26 -0800 (PST) X-Received: by 10.31.52.71 with SMTP id b68mr665377vka.13.1515261446019; Sat, 06 Jan 2018 09:57:26 -0800 (PST) In-Reply-To: <86c40631-4189-4c9c-b664-b2f27dde53b6@isocpp.org> X-Original-Sender: jmckesson@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:36516 Archived-At: ------=_Part_8928_880883753.1515261445431 Content-Type: multipart/alternative; boundary="----=_Part_8929_64043451.1515261445431" ------=_Part_8929_64043451.1515261445431 Content-Type: text/plain; charset="UTF-8" On Saturday, January 6, 2018 at 12:07:22 PM UTC-5, schreiber...@gmail.com wrote: > > On Saturday, January 6, 2018 at 5:33:08 PM UTC+1, Nicol Bolas wrote: >> >> My overall point is this. >> >> We can all agree that `[1, 2]` would be ideal. But because this already >> has meaning in C++, we can't change it without going through a round of >> deprecation. So you'd be looking at 6-9 years before we could even add the >> language feature that lets us give `[1, 2]` the meaning we want. >> >> Is this feature worth that wait? Is it worth the effort of deprecating >> comma expressions in brackets? Or should we just encourage the use of >> alternatives? >> >> I say it'd be easier to add a language feature to allow `[{1, 2}]` to >> work on language arrays than to make `[1, 2]` work. Let's canonize that >> idiom by adding it to the language. That's something that could (in theory) >> happen in the C++20 time frame, since it doesn't break backwards >> compatibility. >> >> So you can either wait 6-9 years for perfection, or get something right >> now that is almost as good. >> > > To reply to your previous message, yes I think people get turned off C++ > because of small awkwardness like these. Of course it's not one such little > detail that tips the balance, but the whole package of it. We're slowly > making things simpler with each iteration of the language (range-based > loops, auto, etc), and I think we should continue down that road to make > C++ as intuitive to use as possible, if it is to compete with cute newborn > languages. > > As for your proposal. Consider someone new to the language seeing the > "[{1,2}]" construct, and wondering why it is spelled like this. > Why do they care? A new user needs to learn that things are spelled as they're spelled. "Why" is not an important matter for their learning at this point. Syntax is whatever it is*.* > Can you imagine what they will think when they are told "yeah, it is > because [1,2] is a valid syntax that throws away 1 and uses 2 as an index"? > But that's not why. They should be told "The expression `1, 2` is a valid expression that throws away 1 and uses 2. So we wrap it up in an initializer list so that it will be treated as a sequence of values and not an expression." That `[]` is involved is not really the point. My bet is on "why on earth would someone want that? and why is it given a > simpler, more accessible syntax?". It does not inspire trust in how the > language was designed. > This one wart will not be noticed among the* thousands* of other warts C++ has. And however much you may think things in C++ are becoming simpler, the number of warts increases with each revision. Structured binding is quite a wart. Having comparison operator overloading other than `operator<=>` is a wart. Overloading `operator<<` for writing to streams is a wart. And so on. Also, the "accessible" argument is trivial at best. You're talking about two characters here. They're even free to think of `[{` and `}]` as being the opening and closing syntax. It's perfectly reasonable to just tell new users "that's the syntax; there is no 'why'." So I'm willing to wait for perfect. If I know anything about C++ > standardization, is that 6-9 years of wait is as good as it gets ;) > It's not just about the wait time. It's also about the pain of it. Getting such a change standardized will not be easy, nor will people changing their code be easy. Those facts, coupled with the relative unimportance of the eventual goal, makes it highly unlikely that this would get standardized. The committee has better things to spend time on, and C++ users have better things to do than add `()` to perfectly functional code. It isn't worth the wait, and it isn't worth the code changes. The perfect syntax isn't worth the effort needed to get there. -- 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/e081dc5c-5d3c-49a5-bfd8-099cf715af64%40isocpp.org. ------=_Part_8929_64043451.1515261445431 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Saturday, January 6, 2018 at 12:07:22 PM UTC-5, schreib= er...@gmail.com wrote:
On Saturday, January 6, 2018 at 5:33:08 PM UTC+1, Nicol Bolas wrot= e:
My overall = point is this.

We can all agree that `[1, 2]` woul= d be ideal. But because this already has meaning in C++, we can't chang= e it without going through a round of deprecation. So you'd be looking = at 6-9 years before we could even add the language feature that lets us giv= e `[1, 2]` the meaning we want.

Is this feature wo= rth that wait? Is it worth the effort of deprecating comma expressions in b= rackets? Or should we just encourage the use of alternatives?
I say it'd be easier to add a language feature to allow `[{= 1, 2}]` to work on language arrays than to make `[1, 2]` work. Let's ca= nonize that idiom by adding it to the language. That's something that c= ould (in theory) happen in the C++20 time frame, since it doesn't break= backwards compatibility.

So you can either wait 6= -9 years for perfection, or get something right now that is almost as good.=

To reply to your previous mess= age, yes I think people get turned off C++ because of small awkwardness lik= e these. Of course it's not one such little detail that tips the balanc= e, but the whole package of it. We're slowly making things simpler with= each iteration of the language (range-based loops, auto, etc), and I think= we should continue down that road to make C++ as intuitive to use as possi= ble, if it is to compete with cute newborn languages.

<= div>As for your proposal. Consider someone new to the language seeing the &= quot;[{1,2}]" construct, and wondering why it is spelled like this.

Why do they care? A new user need= s to learn that things are spelled as they're spelled.

"Why" is not an important matter for their learning at t= his point. Syntax is whatever it is.
=C2=A0
Can you imagine w= hat they will think when they are told "yeah, it is because [1,2] is a= valid syntax that throws away 1 and uses 2 as an index"?
<= /blockquote>

But that's not why. They should be told= "The expression `1, 2` is a valid expression that throws away 1 and u= ses 2. So we wrap it up in an initializer list so that it will be treated a= s a sequence of values and not an expression." That `[]` is involved i= s not really the point.

My bet is on "why on earth would s= omeone want that? and why is it given a simpler, more accessible syntax?&qu= ot;. It does not inspire trust in how the language was designed.

This one wart will not be noticed among t= he thousands of other warts C++ has. And however much you may think = things in C++ are becoming simpler, the number of warts increases with each= revision.

Structured binding is quite a wart. Hav= ing comparison operator overloading other than `operator<=3D>` is a w= art. Overloading `operator<<` for writing to streams is a wart. And s= o on.

Also, the "accessible" argument is= trivial at best. You're talking about two characters here. They're= even free to think of `[{` and `}]` as being the opening and closing synta= x. It's perfectly reasonable to just tell new users "that's th= e syntax; there is no 'why'."

So I'm willing t= o wait for perfect. If I know anything about C++ standardization, is that 6= -9 years of wait is as good as it gets ;)
It's not just about the wait time. It's also about the = pain of it. Getting such a change standardized will not be easy, nor will p= eople changing their code be easy. Those facts, coupled with the relative u= nimportance of the eventual goal, makes it highly unlikely that this would = get standardized. The committee has better things to spend time on, and C++= users have better things to do than add `()` to perfectly functional code.=

It isn't worth the wait, and it isn't wor= th the code changes. The perfect syntax isn't worth the effort needed t= o get there.

--
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/e081dc5c-5d3c-49a5-bfd8-099cf715af64= %40isocpp.org.
------=_Part_8929_64043451.1515261445431-- ------=_Part_8928_880883753.1515261445431-- .