220 36518 <3bdde330-5e80-4408-a15f-b5f09b30fedc@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: schreiber.corentin@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: operator[](...) Date: Sat, 6 Jan 2018 10:50:03 -0800 (PST) Lines: 227 Approved: news@gmane.org Message-ID: <3bdde330-5e80-4408-a15f-b5f09b30fedc@isocpp.org> 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_8940_2097446925.1515264603620" X-Trace: blaine.gmane.org 1515264488 23803 195.159.176.226 (6 Jan 2018 18:48:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 6 Jan 2018 18:48:08 +0000 (UTC) Cc: schreiber.corentin@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCQLNPVMQILRBXFUYTJAKGQEACDKIOY@isocpp.org Sat Jan 06 19:48:03 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f70.google.com ([209.85.213.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eXtVi-0005oy-TK for gclcip-std-proposals@m.gmane.org; Sat, 06 Jan 2018 19:48:03 +0100 Original-Received: by mail-vk0-f70.google.com with SMTP id x205sf4540637vkx.8 for ; Sat, 06 Jan 2018 10:50:06 -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=oIc9Ro4btRbuWUqTnZs/YOHOBmbwqBDj5ucL1IfIgq0=; b=m3Zf/MMTDX/NJg3+K1K4MIl5oUV6grvC5JTZBc9U/nOIN5cd/Jql0z2ya3frgtfYfg Hff4vYY+brLCISiBMtffw2F8UtljV+/Zs9rQZctnkw0gPXjq600oX/EI5orIzwHDPzDb Gqq37cfdY7bBvBC7gPeq4vbrvD+9EflREDEUjud/XOpeJTYIssHBcF8F7urGN4c5ML4U 5tTROgyE8VivE43FGJhdYg+LpZHCK+xYnFlmArJSbLgBRtAynard2KOvZoxWgrU8EpFB WNFNBEwQDFRZ3IpMEZilAphYf6WaPLjj8983avQdPI2OfTtAgesUTnaWDeG5uC3cLQVD kw7Q== 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=oIc9Ro4btRbuWUqTnZs/YOHOBmbwqBDj5ucL1IfIgq0=; b=tFI6QGmxLnBCTgoV+NuNwUVwlCsrJ37JWF72bvMu8Z2yeqP6gXqoVjoG3IzNpiBQbE bQhp+5CS4JxJSc6Jyq7bChDyph1bsFYiOsJ+4ZuGSCgLFzaqZdWRuRzwbZMPQxLxXE4Y uVCiwkFuBh0snE5Rv9uf2hH2GLAlimDDhEJQnrn45DAFeGN/EZYX5n/mWLx1lM3PWErU fgoB4SqtEgxbN3lKTXva4i086AzRKooFDLupiWskhDUxxW+BgitqkUu2mm+KDRaifliQ vvXGDvw5JKlupq0aGGPyUSQLe9GmvuSav29Ylq1gB+SyG30wSSnEEBiiga8fv1GJX6Z5 PgVg== 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=oIc9Ro4btRbuWUqTnZs/YOHOBmbwqBDj5ucL1IfIgq0=; b=LCrTV768v6ynfiDW415dhbnlIoEWOHwXMFoM/aFUz0Ludr35/59bPLBq2IIqI0IjCh f/9s9rYeO485Bb+yuxx/CNJxu+SH+IsXAD/ftEb2rSBLsi3Bg3BKMtKZVSAK6yLtgjwC tsqHn5z3jrAf9W3dh13lmm8jAejhvAqmiFiC9sqfAE14GHkBLOSo0sLweweHrIn9h+aQ /vMe3TrRVzYF7fgWr7moPNHmKq42bfe2YgiAq2HFtUK6AIp5fvtt2H0RgPa8OEZ0i9vB uZruPDKL2pPbj17LrT6ceCSuNNOONaAGWxzxWAMX0/tNk4DCS7JJnTxqC45RuKuMiN1N xLfg== X-Gm-Message-State: AKwxyte1CdIWGXQvWjIT5lIpBXbvaUWHHfodTJX7+LXMIZMhA1JS3w/P ci17Z0itZ/iIlgeIofjANayxuw== X-Google-Smtp-Source: ACJfBovApzZ3d/hZpRfbaODiXgoUvYDU+E0TYLc1bhZW8P2cQ4uZBDyf4N5Q+P9B4JNnSGZZxNAZng== X-Received: by 10.176.76.223 with SMTP id e31mr2669113uag.77.1515264605864; Sat, 06 Jan 2018 10:50:05 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.27.91 with SMTP id n27ls1926555uai.4.gmail; Sat, 06 Jan 2018 10:50:04 -0800 (PST) X-Received: by 10.31.170.131 with SMTP id t125mr681168vke.6.1515264604331; Sat, 06 Jan 2018 10:50:04 -0800 (PST) In-Reply-To: X-Original-Sender: schreiber.corentin@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:36518 Archived-At: ------=_Part_8940_2097446925.1515264603620 Content-Type: multipart/alternative; boundary="----=_Part_8941_2045039583.1515264603620" ------=_Part_8941_2045039583.1515264603620 Content-Type: text/plain; charset="UTF-8" On Saturday, January 6, 2018 at 6:57:25 PM UTC+1, Nicol Bolas wrote: > > 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*.* > For the first few lessons/tutorials maybe, but not in the long run. Understanding "why" is an essential part of learning. At least that is how I learn. > > >> 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. > True, but that does not make it any better :) These are lot of concepts required to understand a statement that should be among the most basic in the language. Comma operator. Initializer list. Construction of a temporary. And that `[]` is involved is precisely the point, because the user will want to understand how array indexing works, and they will have to go though all the aforementioned bits to get their answer. > > 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. > Because it is so central to how I write C++, I have certainly noticed it. And seeing how this topic comes back regularly, the OP and I are not the only ones. While you are probably right that the number of warts has increased as new features were added to the language, I think the "core" of C++ (i.e., the code that the 90% writes) globally has less warts. Otherwise the comity would be doing a poor job. 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. > Waiting is cheap. I've been doing it for years for things like reflection, or modules. It hasn't cost me anything so far ;) And code changes I am convinced are so few as to be non existent. I think you are overestimating the usage rate of this odd pattern, which IMO is such bad practice that it ought to be ill-formed and deprecated regardless of our present discussion. -- 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/3bdde330-5e80-4408-a15f-b5f09b30fedc%40isocpp.org. ------=_Part_8941_2045039583.1515264603620 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Saturday, January 6, 2018 at 6:57:25 PM UTC+1, Nicol Bo= las wrote:
On = Saturday, January 6, 2018 at 12:07:22 PM UTC-5, schreiber...@gmail.com wrote:
On Saturd= ay, 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 be= cause 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 befor= e we could even add the language feature that lets us give `[1, 2]` the mea= ning 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) h= appen in the C++20 time frame, since it doesn't break backwards compati= bility.

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

To reply to your previous message, yes I think p= eople 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 p= ackage of it. We're slowly making things simpler with each iteration of= the language (range-based loops, auto, etc), and I think we should continu= e down that road to make C++ as intuitive to use as possible, if it is to c= ompete with cute newborn languages.

As for your pr= oposal. 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 th= ings are spelled as they're spelled.

"Why= " is not an important matter for their learning at this point. Syntax = is whatever it is.
For the first few le= ssons/tutorials maybe, but not in the long run. Understanding "why&quo= t; is an essential part of learning. At least that is how I learn.
=C2=A0
=C2=A0
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 no= t why. They should be told "The expression `1, 2` is a valid expressio= n 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.&quo= t; That `[]` is involved is not really the point.
<= div>True, but that does not make it any better :) These are lot of concepts= required to understand a statement that should be among the most basic in = the language. Comma operator. Initializer list. Construction of a temporary= .. And that `[]` is involved is precisely the point, because the user will w= ant to understand how array indexing works, and they will have to go though= all the aforementioned bits to get their answer.
=C2=A0

My bet is= on "why on earth would someone want that? and why is it given a simpl= er, more accessible syntax?". It does not inspire trust in how the lan= guage was designed.

This one wa= rt will not be noticed among the thousands of other warts C++ has. A= nd however much you may think things in C++ are becoming simpler, the numbe= r of warts increases with each revision.
Becau= se it is so central to how I write C++, I have certainly noticed it. And se= eing how this topic comes back regularly, the OP and I are not the only one= s. While you are probably right that the number of warts has increased as n= ew features were added to the language, I think the "core" of C++= (i.e., the code that the 90% writes) globally has less warts. Otherwise th= e comity would be doing a poor job.

It's not just about= the wait time. It's also about the pain of it. Getting such a change s= tandardized will not be easy, nor will people changing their code be easy. = Those facts, coupled with the relative unimportance of the eventual goal, m= akes 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 tha= n add `()` to perfectly functional code.

It isn= 9;t worth the wait, and it isn't worth the code changes. The perfect sy= ntax isn't worth the effort needed to get there.
Waiting is cheap. I've been doing it for years for things = like reflection, or modules. It hasn't cost me anything so far ;) And c= ode changes I am convinced are so few as to be non existent. I think you ar= e overestimating the usage rate of this odd pattern, which IMO is such bad = practice that it ought to be ill-formed and deprecated regardless of our pr= esent discussion.

--
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/3bdde330-5e80-4408-a15f-b5f09b30fedc= %40isocpp.org.
------=_Part_8941_2045039583.1515264603620-- ------=_Part_8940_2097446925.1515264603620-- .