220 36517 article Path: news.gmane.org!.POSTED!not-for-mail From: Richard Hodges Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: operator[](...) Date: Sat, 6 Jan 2018 19:18:39 +0100 Lines: 337 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a1140d95833818005621f9863" X-Trace: blaine.gmane.org 1515262613 24358 195.159.176.226 (6 Jan 2018 18:16:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 6 Jan 2018 18:16:53 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD4PBM7UWAHRBANGYTJAKGQE7BHMCFA@isocpp.org Sat Jan 06 19:16:49 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f71.google.com ([209.85.214.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eXt1L-0005M5-D3 for gclcip-std-proposals@m.gmane.org; Sat, 06 Jan 2018 19:16:39 +0100 Original-Received: by mail-it0-f71.google.com with SMTP id f185sf4374341itc.2 for ; Sat, 06 Jan 2018 10:18:42 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1515262722; cv=pass; d=google.com; s=arc-20160816; b=NjmWD23KJErhw2/7iy36tKgqxw/I5Xf0XewSS+8UfZYXuKm862vYAHnwCWjOLcMibH eDFaFyHDG1Minaa3YAdRFJ5v2y39BFn2VDgwUNydVhnUxEEM1XSti34MnFYt43YL2a9X DtxvZDUP98CRO2Npa0doaMec9i7Jl/HqW8IlLi5xJomMnN2ZWxnfOwtr4BKJIZ/llaaN 79Tq44lBgPn6oku5vbKkZduAM3qtGCEAxDzS7eHaGMf6ftHfp14cL2TCmrexMx5kyfgY racR2GuPDkO5dWc/87vkOliw+hbkWfvymdCi+A+sJy4lN8vdFZrM5uE7NWNnRjK0wYjJ Ce6A== 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:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=Bg8OnQUp1E3e4B4Jcr4lO1gel+qYZ/9pUMl5XB+qkwk=; b=mLJN/A7ZCFiCTPTSxsBmjbBluc965vBZgKCEBeVOJhCDidWkXdqlzAUO6ed/dImr3b L8LpwOUWUm07r7ihrJsf7lvHs+pXrds/4vmo6krYrDGGrQJZG0D1iifpOwC1YDv3v8/G +3VWytedn7ch85B7ujJhRed8b/AwH7J4qbKnch8JseXL0bNUqA/4kWUBFG75GDiQyZyE GGlkWtLS91ANhIUw3QPzEmjj3fy89quBB/bX0YWrcxdDJPfxSTh+rKOWPiyKhAomlSSc Dp5S6XBetez0fIzqWmOw0qeN4ZBtrxZwjdMfBCIcxnn/7gVEExo7DzKC77gnmUi6M47G WLOA== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OaE8mK1S; spf=pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=hodges.r@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :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=Bg8OnQUp1E3e4B4Jcr4lO1gel+qYZ/9pUMl5XB+qkwk=; b=qfXUsMae/eUfbqqc7yI1sLc6dkG7PTwhEojsXI5Cm1CLbIModmI8Zuro9OLFuKotT8 a+ZLLyJAXCoQfiv5D6Lh6bD0HN4N957MfFqhfAzaAhzT981/INKCvgGfKhehawxD7Ncs J4doe8Sg3LgkxqehJpV4jbQ5Igfr/+wDNEUPq8mkkECe8qkh88QYyibvBQJlN11CM0my GmXVGw2wa9MOsjnVJlq3jkJ4p0jM2cNFgoMtcWH/I+Q065hMTMClolXiREL3FUoGnJ8C 2/YBb17vNresndJDEleBgPIPWSZIjdzXKYeUrWKzc9NOl2x6DI1aGdirsTKuN8kC5jUH mfsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to: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=Bg8OnQUp1E3e4B4Jcr4lO1gel+qYZ/9pUMl5XB+qkwk=; b=noe/qP9JbOjORCpX3w5woHtCoJZpHAtnjXjL8hMfFLnrgYOTcQqc6o7HmQFJDYlRSu 9KmW4lqBQUKSm7oHAreivNb0shs65b/7drmu/tujxEwVpmaUp04+Hw58QBfMYEzI35ws 9HWRJedAwlMjB7JKOJFOdTeMZBymzotAO4u6YkmcO63dIu35GOU0/+LpDntSjkHhiRR7 Qp0sCcwwf6Pgyf8vqKuB+qz9hgZdDSQi+Lzi18AMngdrC2L2u5QxU3ULTHYzhA3t9iX1 mAdXXWcKDziSJwu8kpvAFRjMaOKuTlQBAWNPoGvC/KINxtF7PGxlMu2jWyAxZoXZ/S2n dYww== X-Gm-Message-State: AKGB3mJmNbC6ZJrFyPXgke57MDgVMEsht5f1RnckmT0KHd2Oig/CavHq biW916mWY6ugki22YaKie30vCA== X-Google-Smtp-Source: ACJfBosI5oDPLOPzFZe3n1ZVG+mcNNCyDOegGUfzu1mIc7s1zl1iCDlvDlT9IXNzxk7fahnc53aN8w== X-Received: by 10.36.77.195 with SMTP id l186mr4675873itb.40.1515262722171; Sat, 06 Jan 2018 10:18:42 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.164.22 with SMTP id n22ls1055370ioe.12.gmail; Sat, 06 Jan 2018 10:18:41 -0800 (PST) X-Received: by 10.107.11.86 with SMTP id v83mr6904909ioi.248.1515262721110; Sat, 06 Jan 2018 10:18:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1515262721; cv=none; d=google.com; s=arc-20160816; b=C+vMj6vJqIKmDlnVQoI99aU+y9aDSqCu3A0rueFhH5q/n58H0BzxBq4edR8mSygn9L HEh33cHRYuorLNV3/AD5DQHHnaBtssTdmsAqCV9WBSXnSUkiotC9snNWe5NkFc9Y8+bJ dvlb7qFzreZj/Aw1ZJY5/qUE5XPR5MVj/+O+M8NGF/IafRt8h+yT0xr27F3vRYzFIp9c D75PQ/MqBY5yfoo/GjEACpP7ITRmHHUgPJUZHTj7/9RiIG4l3cc+rZFq7y1megn/qpow MItWPVQN0iZwAe/eJrLXhMGun4QO2GrG6IkRIWFg4KvSGV8cFaP/VpaLWxUev26Z38df u5QQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=B+XNTu78fub9VovayNeA3jcxgpZ61fekatqSoL+SSg0=; b=nWSUMK2M3+ft9qjKGLAgyqx94N6V1ht27W6iZHcOrvP19Nk5eGHsfs+lNMBQTyCBf3 2eVCd1f1zfuLXt57CNk8y/Cv/JSahq27A2iRwqhVSZCyNSvgV19aGjpCe5PUXnOLMflc YMqn3TWtj/lYwmaK/yNkKzAVdaMSSZBsXxN0ewXZnvr7ecqkqABWpw6mjVCg11lM781Q meVEmxJ/VqCIY4oLSAvK2yuLva/MliKf/SSyj8hQA4O5NyxLKYapvA7oUDwqvS2/dtWK g09DIAGrs3fN5/YvI+Qd7a58sedm6GFB3o+M2ADt/pOz/wpei0xfUTuxMuhLUbuR68ES 1ckQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OaE8mK1S; spf=pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=hodges.r@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id y19sor3790955ioy.293.2018.01.06.10.18.41 for (Google Transport Security); Sat, 06 Jan 2018 10:18:41 -0800 (PST) Received-SPF: pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.107.154.195 with SMTP id c186mr6427228ioe.41.1515262720572; Sat, 06 Jan 2018 10:18:40 -0800 (PST) Original-Received: by 10.2.181.55 with HTTP; Sat, 6 Jan 2018 10:18:39 -0800 (PST) In-Reply-To: X-Original-Sender: hodges.r@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OaE8mK1S; spf=pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=hodges.r@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=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:36517 Archived-At: --001a1140d95833818005621f9863 Content-Type: text/plain; charset="UTF-8" I think there's a way to move the [1, 2] syntax forward a little more aggressively while reducing compatibility clashes. given the expression x, y This currently means "evaluate x, evaluate y, return a [prvalue?-]reference to y" Imagine there is a small language such that what it actually produced was a std::comma_expansion as if by: return std::comma_expansion { x, y }; And that a comma_expansion&& was implicitly convertible to decltype(y)&& Now, legacy operator[] methods would continue to work, as would a new operator[] written to accept a std::comma_expansion: (quick and dirty) example code: #include #include namespace std { template struct comma_expansion : std::tuple { using underlying_tuple = std::tuple; comma_expansion(comma_expansion const&) = delete; comma_expansion& operator=(comma_expansion const&) = delete; using underlying_tuple::underlying_tuple; static constexpr std::size_t size() { return sizeof...(Ts); }; static_assert(size() != 0, ""); using last_type = decltype(std::get(std::declval())); using last_rvalue_ref = std::add_rvalue_reference_t; operator last_rvalue_ref() && { return std::get(std::move(*this)); } }; } struct array_2d { auto operator[](int y) { // as before } auto operator[](std::comma_expansion&& xy) { // now detects [1, 2] } }; int main() { // with a small compiler change, this could be written as // int test = 1, 2; int test = std::comma_expansion{ 1, 2 }; assert(test == 2); array_2d a; // and this could be written as // a[4, 5]; a[std::comma_expansion{ 4, 5 }]; } On 6 January 2018 at 18:12, Jake Arkinstall wrote: > > > On 6 Jan 2018 16:33, "Nicol Bolas" wrote: > > On Saturday, January 6, 2018 at 10:53:33 AM UTC-5, Jake Arkinstall wrote: > >> >> On Sat, Jan 6, 2018 at 3:41 PM, Nicol Bolas wrote: >> >>> Are you* seriously* telling me that people would use C++ for these >>> applications, but are warded off just because they can't use `[]` and would >>> have to resort to `()`? I find myself doubtful that any person is picking >>> languages based on trivial syntax like that. >>> >>> I think you're exaggerating the importance of this syntax. >>> >> >> I agree with you that this is far from a reason to abandon the language. >> That being said, it is still a part of the language that IMO is in need of >> improvement, which is why we're here. >> > > 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. > > > I understand that, and waiting 6-9 years is fine with me. For things like > this, it's worth it. > > That being said, I'm only 99% convinced that we *need* deprecation before > reaping the benefits. The 1% is hanging to the idea of making this only > impact cases where operator[] has multiple arguments, which is currently a > compilation error and thus this cannot impact legacy code, and deprecate > the comma operator for single argument operator[]s. Is this something that > would take a lot of effort for compilers? > > Even if that 1% hope gets shot down, I'm still happy waiting through the > deprecation period. Making do with what we already have is not progressive. > > -- > 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/CAC%2B0CCNhTj2iP-LHbKsVyf%3Dgm- > iwnCe7j3aMQBwJ1t6tdpu40Q%40mail.gmail.com > > . > -- 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/CALvx3hYJxq72acxWC6vNGvNmCUWNYXw-55PhhozVAmSB_3_7nw%40mail.gmail.com. --001a1140d95833818005621f9863 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think there's a way to move the [1, 2] syn= tax forward a little more aggressively while reducing compatibility clashes= ..

given the expression

=C2=A0 =C2=A0 x, y

<= /div>
This currently means "evaluate x, evaluate y, return a [prva= lue?-]reference to y"

Imagine there is a smal= l language such that what it actually produced was a

std::comma_expansion<decltype(x),= decltype(y)>

as if by:

return std::comma_expansi= on<decltype(x), decltype(y)> { x, y };


And that = a comma_expansion&& was = implicitly convertible to decltype(y)&a= mp;&=C2=A0

Now, legacy operator[] methods would continue to work,= as would a new operator[] writt= en to accept a std::comma_expansion:

(quick and dirty) example code:
#include= <tuple>
#include= <cassert>

namespace= std {

template= <class...Ts>
struct comma_expansion : s= td::tuple<Ts...>
{
using underlying_tuple =3D std::tuple<Ts...>;=

comma_expansion(comma_expansion const&) =3D de= lete;
comma_expansion& operator=3D(comma_expansion const&) =3D delete;

using = underlying_tuple::underlying_tuple;

static constexp= r std::size_t size() { return sizeof...(Ts); };

static_assert(size() != =3D 0, "");

using last_type =3D decltype(std::get<size()-1= >(std::declval<underlying_tuple>()));

= using last_rvalue_ref =3D std::a= dd_rvalue_reference_t<last_type>;

operator last_rvalue_ref() &&
=
{
re= turn std::get<size()-1= >(std::move(*this));
}
};
}

struct array_2d
{
auto oper= ator[](int y)
= {
// as before
}

auto= operator[](std::comma_exp= ansion<int, int>&& xy)
{
= // now detects [1, 2]
<= div> }
};

int= main()
{
// with a small compiler change, this could be written as
// int test =3D 1, 2;
int test =3D std::com= ma_expansion<int, int>{ 1, 2 };
as= sert(test =3D=3D 2);

array_2d a;
// and = this could be written as
// a[4, 5];
a[std::comma_expansion<int, int= >{ 4, 5 }];
}


=


On 6 January 2018 at 18:12, Jake Arkinstall <= ;jake.arkins= tall@gmail.com> wrote:

=
On 6 Jan 2018 16:33, "Nicol Bolas"= <jmckesson@gma= il.com> wrote:
On Saturday, January 6, 2018 at 10:53:33= AM UTC-5, Jake Arkinstall wrote:

On Sat, Jan 6, 2018 at 3:41 PM, Nicol Bolas <jmck...@gmail.com> wrote:=
Are you se= riously telling me that people woul= d use C++ for these applications, but are warded off just because they can&= #39;t use `[]` and would have to resort to `()`? I find myself doubtful tha= t any person is picking languages based on trivial syntax like that.=

I think you're exaggerating the imp= ortance of this syntax.

I agree with you t= hat this is far from a reason to abandon the language. That being said, it = is still a part of the language that IMO is in need of improvement, which i= s why we're here.

My overall point is this.

We can all agre= e 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 y= ou'd be looking at 6-9 years before we could even add the language feat= ure that lets us give `[1, 2]` the meaning we want.

Is this feature worth that wait? Is it worth the effort of deprecating co= mma expressions in brackets? Or should we just encourage the use of alterna= tives?

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= 9;s something that could (in theory) happen in the C++20 time frame, since = it doesn't break backwards compatibility.

So y= ou can either wait 6-9 years for perfection, or get something right now tha= t is almost as good.
=
I understand that, and waiting 6-9 years= is fine with me. For things like this, it's worth it.

That being said, I'm only 99%=C2=A0c= onvinced that we need deprecation before reaping the benefits. The 1= % is hanging to the idea of making this only impact cases where operator[] = has multiple arguments, which is currently a compilation error and thus thi= s cannot impact legacy code, and deprecate the comma operator for single ar= gument operator[]s. Is this something that would take a lot of effort for c= ompilers?

Even if that 1= % hope gets shot down, I'm still happy waiting through the deprecation = period. Making do with what we already have is not progressive.
=

--
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-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/CAC%2B0CCNhTj2iP-LHbKsVyf%3Dgm-iwnCe7j3aMQBwJ1= t6tdpu40Q%40mail.gmail.com.

--
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 htt= ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYJxq72acxW= C6vNGvNmCUWNYXw-55PhhozVAmSB_3_7nw%40mail.gmail.com.
--001a1140d95833818005621f9863-- .