220 39012 <66e44c1e-6ec9-4d52-aaf0-7e79a1818d3a@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: mihailnajdenov@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Concepts: Investigating implicit type-name introduction Date: Sat, 7 Jul 2018 13:46:04 -0700 (PDT) Lines: 472 Approved: news@gmane.org Message-ID: <66e44c1e-6ec9-4d52-aaf0-7e79a1818d3a@isocpp.org> References: <0c0da3b7-02f4-4130-9441-5a1385864d39@isocpp.org> <4a42b005-ca66-474c-83ea-4273836db2df@isocpp.org> <07ec2785-ec90-4b72-bdbe-3cf624eac38b@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_92011_1721426187.1530996364479" X-Trace: blaine.gmane.org 1530996240 30812 195.159.176.226 (7 Jul 2018 20:44:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 7 Jul 2018 20:44:00 +0000 (UTC) Cc: zy@miator.net To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBDONQTNAKGQENBPO3IQ@isocpp.org Sat Jul 07 22:43:56 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 1fbu3f-0007tm-Ou for gclcip-std-proposals@m.gmane.org; Sat, 07 Jul 2018 22:43:56 +0200 Original-Received: by mail-yb0-f200.google.com with SMTP id c8-v6sf1871752ybi.19 for ; Sat, 07 Jul 2018 13:46:07 -0700 (PDT) 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=y09UqG22L7RZqPQhFhNwaRb8mmLoim/C5ZjGrZwO6jI=; b=l2t1gAyjFF8aVwZBuWschCp9UoJrqcYHG7aMd9Qa5IbLNCmT0dq3h7jDf7IypLBw/+ cCfWG6O2+DddtED8X0HwJhZyH+BkAbqVyPHUVkVx037+r7CeFpdwSXpvz6eRlJybPfMZ s1wOArP+2JP0PVPInAr5JBOTj9fkVYo7T1Q5A1GPOxRHEFe+XJyUp76Y1X93dFbRcOkK GNaU6j8j5Tj1y1Yfy3puESflnl62coBCbdmsZJ0R7K36g2rzEMeSuoUNBqtlsg1+RcRj zN1Yow0asem60SsVnjpyG3ItTjl1cNGzOHEFj9yqn83IfAFssFjiOrfgpVr1+jRC8+WQ KDEQ== 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=y09UqG22L7RZqPQhFhNwaRb8mmLoim/C5ZjGrZwO6jI=; b=ZGv7Zwdt/FGYxenMhfrV5VGbfMsmj18Da290Zq2013hyRDgPBOoNWKEl7nSnua8rx0 O5caWg/NmfuMs0OTHuQPeCcNuA7i2qXGhvHl1nT7QgkmLB8DEuCtpWRCRXBGth0iG66x wAkhcoPAPFz0AOfjZiofoEf7VB6UcD8QvxkNBLQfmCMkyZOZmKD/5yWi6YMIW52OMxGn kBfSj4sWyg06Oj/vzEMTMpMz//gyuUgXo20Gx0XNd2rS9dwLsZPgG2PTxhlm7DWkuTSB vte3fVj2KEBUR4CDPOnZCgDW1YbUjkBFElJlb07afLtVXaYdJnol7XMmvfNkJ33t5f7Y oXPg== 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=y09UqG22L7RZqPQhFhNwaRb8mmLoim/C5ZjGrZwO6jI=; b=fiyx7bk/2WRpdDBRtKG5VrESxPaIn6RUciYToaTgOVKTBHv0kBTXAh/L37I1iHa+As YisReyOxF74smG2TCPNMZ9c+7wm8WKxYmEIT01R5b5xmlW9AnhaH5aZVNHUMzYwCMkNP YNWx0WmWgCOUe8eN/oZdIy7LR2zbouj8q5ffffuj5qBPjcolnGqBaFAa2gVuSHnHjsZ5 xYgx4eH7sT5ptbtCR/iAXqqixt0ZB+9BfEpl3H3etuRCqVtN00b0AcGKsDvx/b8rSteW 56oR7tTQIOywHAdc6gERSIryDrAQzL4hlaGKdkKp1MRhuyq0HISJ75RWPP5xQQWIICvg /ncw== X-Gm-Message-State: APt69E2Cwc2No85KeJijWHhYnG3qZFeOeujnHrmZg7sVdtJIkMQqlbKq A6550XVXMAYMEq2+Zgs0OvnrRg== X-Google-Smtp-Source: AAOMgpewz1Mxg6Hn3fndNtmygCkiL7Bj4CkUMeoysbgvYgcnUXwYm11CMiRbpeWHd317JgLjbMgj0Q== X-Received: by 2002:a81:6dc4:: with SMTP id i187-v6mr4604238ywc.96.1530996366706; Sat, 07 Jul 2018 13:46:06 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:f009:: with SMTP id p9-v6ls1647083ywm.0.gmail; Sat, 07 Jul 2018 13:46:05 -0700 (PDT) X-Received: by 2002:a0d:f781:: with SMTP id h123-v6mr1947733ywf.2.1530996365026; Sat, 07 Jul 2018 13:46:05 -0700 (PDT) In-Reply-To: <07ec2785-ec90-4b72-bdbe-3cf624eac38b@isocpp.org> 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:39012 Archived-At: ------=_Part_92011_1721426187.1530996364479 Content-Type: multipart/alternative; boundary="----=_Part_92012_1704439453.1530996364480" ------=_Part_92012_1704439453.1530996364480 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Considering=20 class ConcreteType; is an age-old way to introduce a type, can we extend that to Concepts? Concept Type; After all the suggested Concept auto var =3D something(); is not unlike class ConcreteType car =3D something(); And taking a note from in-place we could just let auto be a name of a=20 deduced type=20 Concept Type var =3D something(); I am not that a fan of 2-in-one declaration, but it does help with natural= =20 syntax void advance(Iterator I& i, different_type_t n); I am willing to argue it also looks most natural to the eye as there is a= =20 type next to the name. auto sort(RandomAccessIterator I first , Sentinel S last , All Comp comp =3D less<>{} , All Proj proj =3D identity{}) requires Sortable; On Saturday, July 7, 2018 at 6:12:51 PM UTC+3, Nicol Bolas wrote: > > On Saturday, July 7, 2018 at 2:23:36 AM UTC-4, Zhihao Yuan wrote: >> >> > From: Nicol Bolas =20 >> > Sent: Friday, July 6, 2018 10:04 PM=20 >> >=20 >> >> A wholesome proposal=20 >> >> must base on real code and real demand. So far, neither=20 >> >> Ranges nor Text_view has any demand for anything what=20 >> >> P1141R0 proposes. It looks like at this point we are not=20 >> >> just designing by committee, but also designing for=20 >> >> committee.=20 >> >=20 >> > Pretty much everyone agrees that having terse syntax of some form is a= =20 >> good thing. Real demand for terse syntax of some form is undeniable; jus= t=20 >> ask actual users whether they want it or not.The only question which=20 >> remains is how you spell it. The Concepts TS had one spelling, but it ha= d=20 >> some issues. This proposal resolves those issues in a way that most peop= le=20 >> can live with.=20 >> >=20 >> >> "Real demand for terse syntax of some form is undeniable"=20 >> !=3D " Real demand for terse syntax of any form is undeniable."=20 >> If the proposed syntax doesn't help Ranges, then where is=20 >> the demand? > > > I think the point you're trying to make is that applying the terse syntax= =20 > to most Range algorithms wouldn't make them shorter. Or at least, not muc= h. > > In some cases, the order of parameters directly forbids it. Anytime a=20 > function takes a `Proj` and a `Pred` or a similar functor, the `Proj`=20 > function parameter comes last in the function argument list, but the `Pro= j`=20 > is always before the `Pred` in the *template* parameter list. The reason= =20 > being that lots of users won't need `Proj`, but `Proj` needs to constrain= =20 > `Pred`. > > However, *no terse syntax* would help in those cases. Not the Concepts=20 > TS, not Bjarne's `template` prefix, nor Herb's `{}` syntax. Once the orde= r=20 > of function parameters and template parameters has to differ, you lose th= e=20 > ability to use any terse syntax. > > So let's skip all of those. That's pretty much all of the algorithms. > > Another case is when you need to actually get the name of one of the=20 > deduced types. This is actually quite common: > > template constexpr void advance(I& i, difference_type_t n > ); > > That looks like a prime candidate for terse syntax, but what you get is: > > constexpr void advance(Iterator auto &i, different_type_t n)= ; > > That is shorter... by one character. > > This shows the strength of Herb's syntax: > > constexpr void advance(Iterator{I} &i, difference_type_t n); > > That provides at least some reduction in verbosity. > > =20 > >> Here is a roughly complete list of the=20 >> signatures that can benefit from P1141R0 in Ranges:=20 >> >> destroy_at=20 >> next (1 overload out of 4)=20 >> prev (1 overload out of 3)=20 >> operator=3D=3D, operator!=3D of =E2=80=9Cunreachable=E2=80=9D, 4 ove= rloads=20 >> >> One might say that Ranges is complex -- how would he/she=20 >> prove it, show us a simple real-world Concept-enabled=20 >> library? >> > > On the one hand, I think this is the wrong standard by which to judge=20 > terse syntax. > > That is, any generic conceptualized library will have complicated=20 > relationships between the various parameters. So terse syntax was never= =20 > going to be viable for such libraries. > > The principle users of terse syntax will not be writers of generic=20 > libraries, but *users* of generic libraries. They're useful when you're= =20 > writing a quick lambda to be passed somewhere. `[](UnsignedInteger auto i= )=20 > {}` is going to be easier to digest than `[] (I i)=20 > {...}`. Not massively shorter of course, but still more readable. > > The idea with terse syntax is to keep the simple cases simple. Pretty muc= h=20 > nothing in the Range TS is a simple case. > > On the other hand... the complexity of the Range system I think has reall= y=20 > damaged the utility of terse syntax. > > Consider the original Concepts-Lite proposal=20 > ,=20 > which gave us a number of seemingly common-place examples of where terse= =20 > syntax would be used. In particular, `sort` and `merge`. The Range TS=20 > definitions of these functions evolved to the point where terse syntax=20 > either wasn't possible or wasn't practical (ie: the terse version wouldn'= t=20 > be appreciably shorter). > > For example, the Concepts-Lite proposal suggested this for `sort`: > > void sort(Cont& c); > > Well, in a range world obviously that would be some `Range` concept, but= =20 > the general structure is the same. What isn't the same is how that now ha= s=20 > to be generalized to allow for comparison functors. Using that terse synt= ax: > > void sort(Range &&r, Comp comp =3D std::less decltype(r)>{}); > > Where `Comp` knows how to act on a particular range to extract the value= =20 > type and detect that the functor provides comparisons against that value= =20 > type. > > And of course, once you add projection-based-comparison, this becomes=20 > completely unworkable. Because now you have template parameters in a=20 > different order from function parameters. > > The point being that the more conceptualized a function becomes, the=20 > chance of it being able to use terse syntax *of any form* approaches 0. > > And that suggests a potential problem: laziness. If users of simple cases= =20 > get used to terse syntax, they may avoid doing things that stop them from= =20 > being able to use terse syntax. So rather than write out the complex `sor= t`=20 > in ranges, they'd just write `void sort(RandomAccessRange auto &&r, auto= =20 > comp =3D std::less<>{}, auto proj =3D std::identity{});` and just let it = go at=20 > that. > > Wheresas, if you force them to stick that `RandomAccessRange` in a=20 > template argument list, and deny them the ability to use `auto` in functi= on=20 > parameters, then they have no choice but to spell it out explicitly. And= =20 > since they're having to write it long-form, they may as well constrain it= =20 > properly. > --=20 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 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/66e44c1e-6ec9-4d52-aaf0-7e79a1818d3a%40isocpp.or= g. ------=_Part_92012_1704439453.1530996364480 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Considering=C2=A0

class ConcreteType;

is an age-old way to intro= duce a type, can we extend that to Concepts?
Concept Type;

After all the suggested Concept auto var =3D something();

is not unlike clas= s ConcreteType car =3D something();<= /span>
<= /font>
A= nd taking a note from in-place we could just let auto be a name of a deduce= d type=C2=A0

void advance(Iterator I& i, d= ifferent_type_t<I> n);

I = am willing to argue it also looks most natural to the eye as there is a typ= e next to the name.

auto sort(RandomAccessIterator I first
<= font face=3D"courier new,monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 , Sentinel&= lt;I> S last
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 , All Comp comp =3D less<>{}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 , All Pr= oj proj =3D identity{}) requires Sortable<I, Comp, Proj>;


<= strike>
On = Saturday, July 7, 2018 at 6:12:51 PM UTC+3, Nicol Bolas wrote:
On Saturday, July 7, 2018 = at 2:23:36 AM UTC-4, Zhihao Yuan wrote:
> From: Nicol Bolas <jmck...@gmail.com>= ;=20
> Sent: Friday, July 6, 2018 10:04 PM
>=20
>> A wholesome proposal=20
>> must base on real code and real demand. =C2=A0So far, neither= =20
>> Ranges nor Text_view has any demand for anything what=20
>> P1141R0 proposes. =C2=A0It looks like at this point we are not= =20
>> just designing by committee, but also designing for=20
>> committee.
>=20
> Pretty much everyone agrees that having terse syntax of some form = is a good thing. Real demand for terse syntax of some form is undeniable; j= ust ask actual users whether they want it or not.The only question which re= mains is how you spell it. The Concepts TS had one spelling, but it had som= e issues. This proposal resolves those issues in a way that most people can= live with.
>=20

"Real demand for terse syntax of some form is undeniable"
!=3D " Real demand for terse syntax of any form is undeniable.&quo= t;
If the proposed syntax doesn't help Ranges, then where is
the demand?

I think the point you'r= e trying to make is that applying the terse syntax to most Range algorithms= wouldn't make them shorter. Or at least, not much.

<= /div>
In some cases, the order of parameters directly forbids it. Anyti= me a function takes a `Proj` and a `Pred` or a similar functor, the `Proj` = function parameter comes last in the function argument list, but the `Proj`= is always before the `Pred` in the template parameter list. The rea= son being that lots of users won't need `Proj`, but `Proj` needs to con= strain `Pred`.

However, no terse syntax wou= ld help in those cases. Not the Concepts TS, not Bjarne's `template` pr= efix, nor Herb's `{}` syntax. Once the order of function parameters and= template parameters has to differ, you lose the ability to use any terse s= yntax.

So let's skip all of those. That's = pretty much all of the algorithms.

Another cas= e is when you need to actually get the name of one of the deduced types. Th= is is actually quite common:

template <Iterator I> constexpr void advance<= span style=3D"color:#660">(I& i, difference_type_t<= /span><I> n);

That looks like a prime candidate for terse syntax, but what you get is:=

constexpr void adva= nce(Ite= rator a= uto &am= p;i, different_type_t<decltype(i)> n);

That is shorte= r... by one character.

This shows the strength of = Herb's syntax:

constexpr void advance(Iterator{I} &i, difference_type_t<<= span style=3D"color:#000">I> n);
=

That provides at least some reductio= n in verbosity.

=C2=A0
Here is a roughly complete list of the
signatures that can benefit from P1141R0 in Ranges:

=C2=A0 =C2=A0 destroy_at
=C2=A0 =C2=A0 next (1 overload out of 4)
=C2=A0 =C2=A0 prev (1 overload out of 3)
=C2=A0 =C2=A0 operator=3D=3D, operator!=3D of =E2=80=9Cunreachable=E2= =80=9D, 4 overloads

One might say that Ranges is complex -- how would he/she
prove it, show us a simple real-world Concept-enabled
library?

On the one hand, I think t= his is the wrong standard by which to judge terse syntax.

That is, any generic conceptualized library will have complicated r= elationships between the various parameters. So terse syntax was never goin= g to be viable for such libraries.

The principle u= sers of terse syntax will not be writers of generic libraries, but users= of generic libraries. They're useful when you're writing a qui= ck lambda to be passed somewhere. `[](UnsignedInteger auto i) {}` is going = to be easier to digest than `[]<UnsignedInteger I> (I i) {...}`. Not = massively shorter of course, but still more readable.

<= div>The idea with terse syntax is to keep the simple cases simple. Pretty m= uch nothing in the Range TS is a simple case.

= On the other hand... the complexity of the Range system I think has really = damaged the utility of terse syntax.

Consider the original Concepts= -Lite proposal, which gave us a number of seemingly common-place exampl= es of where terse syntax would be used. In particular, `sort` and `merge`. = The Range TS definitions of these functions evolved to the point where ters= e syntax either wasn't possible or wasn't practical (ie: the terse = version wouldn't be appreciably shorter).

For = example, the Concepts-Lite proposal suggested this for `sort`:
void sort(Cont& c);

Well,= in a range world obviously that would be some `Range` concept, but the gen= eral structure is the same. What isn't the same is how that now has to = be generalized to allow for comparison functors. Using that terse syntax:

<= div>void sort<= /span>(Range &&am= p;r, Comp<decltype= (r)> comp <= /span>=3D std<= /span>::less<value= _type<decltype(r)>{});

Where `Comp` knows how to act on a particular= range to extract the value type and detect that the functor provides compa= risons against that value type.

And of course,= once you add projection-based-comparison, this becomes completely unworkab= le. Because now you have template parameters in a different order from func= tion parameters.

The point being that the more= conceptualized a function becomes, the chance of it being able to use ters= e syntax of any form approaches 0.

And that= suggests a potential problem: laziness. If users of simple cases get used = to terse syntax, they may avoid doing things that stop them from being able= to use terse syntax. So rather than write out the complex `sort` in ranges= , they'd just write `void sort(RandomAccessRange auto &&r, auto= comp =3D std::less<>{}, auto proj =3D std::identity{});` and just le= t it go at that.

Wheresas, if you force them to st= ick that `RandomAccessRange` in a template argument list, and deny them the= ability to use `auto` in function parameters, then they have no choice but= to spell it out explicitly. And since they're having to write it long-= form, they may as well constrain it properly.
<= /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 https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/66e44c1e-6ec9-4d52-aaf0-7e79a1818d3a= %40isocpp.org.
------=_Part_92012_1704439453.1530996364480-- ------=_Part_92011_1721426187.1530996364479-- .