220 39129 <9df59e26-2363-4119-9794-090f958c4499@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Concept-defined placeholder type Date: Thu, 12 Jul 2018 17:50:00 -0700 (PDT) Lines: 368 Approved: news@gmane.org Message-ID: <9df59e26-2363-4119-9794-090f958c4499@isocpp.org> References: <0fe92570-1bc7-4a8b-aaf4-b272950f20af@isocpp.org> <8ba6d594-0aa8-4c6c-87b1-b785cc519570@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4133_152517083.1531443000458" X-Trace: blaine.gmane.org 1531442876 1482 195.159.176.226 (13 Jul 2018 00:47:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 13 Jul 2018 00:47:56 +0000 (UTC) Cc: zy@miator.net To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBOPOT7NAKGQE7KH46GQ@isocpp.org Fri Jul 13 02:47:52 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f199.google.com ([209.85.161.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fdmFT-0000HE-Hz for gclcip-std-proposals@m.gmane.org; Fri, 13 Jul 2018 02:47:51 +0200 Original-Received: by mail-yw0-f199.google.com with SMTP id f206-v6sf27841742ywa.11 for ; Thu, 12 Jul 2018 17:50:02 -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=s4kQDZ9YQdDm1iv1J7QMJxX+2fBKMLX4vX6YVGhvm0o=; b=EZtVWR5Md0vtFYU+jIcdi0vVxk/JEY+DKZmrHXFZ6+lboXu80AJq8uWuYcXqIawprr dyduRApdpTW5opwsaVqhJqXwD/OdURCgXQSthxnZW7rzohTELgFLi2qpIVNRrGP43qY6 nYkg99cFE8X8o37gnNGhmQfxwa8xnG8ahuVj9eas+jzv78JU4hbFCR1FmZ+yx/qZgIbj veZHWeomfSBbFMgu5RoEjS2hV1PIGXZ1cdny+c69Td5gnMUDcPw8h1oNZhVGocTiUNM/ XGeCISdjcHKzGXScEY0HV+tRjC5o8NpoIgZG90nqouPmE6WlmZvlz+5mhFj/yjoGWJvY skSQ== 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=s4kQDZ9YQdDm1iv1J7QMJxX+2fBKMLX4vX6YVGhvm0o=; b=fZsvNQlqBkpSpaqilvb0BlbrjzGUSzX8ATp8CNP8RMs1yL2zX5HztJVDkPLmy6WFg3 RN/+QewuzkKB1Ry+s8CNwGWVtBSpJZdVhCHHsfci6wfMbR3vaewr5daNYeGzurzELzNX JNnckgQ6z12JOZr+ZBwqq8KPINg3I6VW764Og/MF9ojJ1ypCZUtFNkZw2uPxhpOVHpLR +pT5C76Dou31ZqtOeRLWgtVe9uUYQEE8dOm2is9Sx+sYMxTdI5xqW+6hwRrESexq44Ev jALg+N1bHDL47t6aHhLldTyefpHkH9/nuPB+q80Rjm1ryLsPDuBcObz8Irjknm827ASl VxFQ== 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=s4kQDZ9YQdDm1iv1J7QMJxX+2fBKMLX4vX6YVGhvm0o=; b=fXUrN8cTsily2t+z3zE9NTBBQe9evbda1r3slZr5tfGYXC8qpGAdh4OI1XM9F2yMpE +9mUq+4WeUJfnO+So6tRdQErGGoWcu4xXDqYQzF3rTTCCCXByA+8nwd8jCCEjj3JzOXv +AlVwfjfv41pAO6rptbNffcRSY4OC5Xck9kO1Vvtv471mHQDzeoGh94B5vypGQ8Hd1+K GxYebEN8Dp1ehpaG6brZLHWvUna4MalKXRZWhQtfdWz/INm+twz82Xt6WOthrOo+Ni1W M5hq6PVUcB74G4Ad7jlyayFCxHRWLNepjjTPs4yL5W+e0gLm2f9farJh932yA9ucVfIT jFSQ== X-Gm-Message-State: AOUpUlH6sRmikUY5DWC0Hj7sw/upST0IAKo37N9uJwLyO5yqA0w/Dy6J Ext091+qkbRvE6aEb6RC/h0VAg== X-Google-Smtp-Source: AAOMgpcGrozdf/zuaxPkk6cYedgDpKgv14pLBM+uU2av/CIr0V8J1/dIQxXIDAPWWoynp1syKLvD2w== X-Received: by 2002:a81:102:: with SMTP id 2-v6mr1381213ywb.128.1531443002097; Thu, 12 Jul 2018 17:50:02 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:2fd2:: with SMTP id v201-v6ls6540151ybv.10.gmail; Thu, 12 Jul 2018 17:50:01 -0700 (PDT) X-Received: by 2002:a25:5f4a:: with SMTP id h10-v6mr437011ybm.5.1531443000979; Thu, 12 Jul 2018 17:50:00 -0700 (PDT) In-Reply-To: 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:39129 Archived-At: ------=_Part_4133_152517083.1531443000458 Content-Type: multipart/alternative; boundary="----=_Part_4134_482941154.1531443000458" ------=_Part_4134_482941154.1531443000458 Content-Type: text/plain; charset="UTF-8" On Thursday, July 12, 2018 at 4:13:56 PM UTC-4, Zhihao Yuan wrote: > > From: Nicol Bolas > > Sent: Thursday, July 12, 2018 10:51 AM > >> > >> Copyable T; > >> T x = foo(); > >> Copyable x = foo(); > >> > >> strictly speaking, they can coexist. > > > > Syntactically speaking, they can coexist. But if a terse syntax proposal > is accepted, then your proposal becomes redundant. That is, there's nothing > your proposal can do that a terse one couldn't. > > Not redundant comparing to papers other than Herb's, > as others do not introduce a type-name. > That's because they don't need to; you can introduce a typename if you want using existing tools. In order for your tool to be superior, you need to explain why: Concept T; T var = ...; is better than Concept auto var = ...; using T = decltype(var); There is no question that they both accomplish the same end. They both are two lines long. The only difference between them is that... well, in the second case, the `using` declaration is entirely optional. If you don't need the typename, you don't have to fetch it. In your case, it must be fetched explicitly. You have yet to explain why your method is superior. >> We don't have enough C++20 code to tell whether > >> this is a real issue. > > > > We don't need C++20 to know whether people frequently need type names > for auto-deduced values. We have plenty of experience with `auto` since > C++11. And while it certainly does happen, it would be difficult to say > that it happens more than 25% of the time you use `auto`. > > > > This is especially true if you're among the Almost Always Auto crowd, > since they deduce variables as a matter of course. > > > > Also, don't forget that Concepts TS is a real thing with real users > behind it. You could ask them. > > No evidence shows that the time we use `auto` is > getting close to the time we constrained-type-specifiers, > there are plenty of cases where constraining is > unnecessary. Um, if what you're saying is true, you *do* realize that you're arguing against your own feature, right? Because if people don't want to constrain their deduced variables... what do we need your feature for? I checked text_view's code and had > yet find a use of constrained-type-specifier. > > >> I can raise a hypophysis saying > >> "repeated constraints happens frequently:" > >> > >> Iterator T; > >> T a = begin(...); > >> // ... > >> T ed = find(...); > > > > But we don't need data, because the alternatives work and don't take up > more lines of code: > > > > Iterator auto a = begin(...); > > using T = decltype(a); > > // ... > > T ed = find(...); > > If decltype(a) is acceptable, why we need to > constrain `auto` at all? > The purpose of constraining `auto` deduction is to prevent errors, to verify that the type being used in the expression has the operations that you think it does. The purpose of getting a typename for a variable is to *get its typename*. These are entirely orthogonal actions. One user may want a typename even for an unconstrained deduced variable. Another user may not care to get the typename for a constrained deduced variable. Neither feature in any way affects the need for the other. I don't understand what you're getting at with this question. > EqualityComparable auto a = ..., b = ...; > > > > Normally, `auto` deduction of multiple variables have to agree in types, > but for constrained deduction, we can allow them to deduce different types, > so long as the constraint has different types to deduce. > > That syntax is indistinguishable to > > Copyable auto a = ..., b = ...; > > Different types, each satisfying Copyable, rather than > satisfying EqualityComparable. > My point is that your statement that there's no way for terse syntax to be used for multiple deductions is incorrect. Maybe that particular syntax wouldn't work (though since it's new syntax, we could require that constrained declarations make the number of variables match the number of template parameters), but I mentioned other syntaxes that certainly could work. > My point in bringing that up is that we already have a way to do that. > The idiom is `auto a = ...; using T = decltype(a);`. That's the idiom all > of the terse syntaxes would use for this too, and therefore they would be > consistent with unconstrained `auto` use. > > > > In order to create an equally consistent idiom, you now have to create > an "Any" concept, apply it to a `T`, then use that `T` to "constrain" a > deduced variable. Why is that better? > > There is no such idiom. I'm not sure what you are saying. Are you saying that people who want to deduce a variable and access the deduced typename don't use `decltype(variablename)` to get it? Or that they don't use `using T = decltype(variablename)` to get it? Because the latter is merely a question of whether they need a shorthand. And if it is indeed the case that users usually don't need a shorthand, then your syntax comes up short, since it requires the creation of that shorthand in order to constrain a variable at all. If there is then we are wasting > time here, static_assert(Copyable) we'are > done. > Everything we're talking about is syntactic sugar. The effectiveness of syntactic sugar is ultimately based on how commonly it will be used, and how much of a pain the alternative is. People want to constrain their variables with concepts, and the `static_assert` method is a painful alternative. So we know there is a demand for a feature that handles this problem. The question is what the best solution is. And thus far, you haven't explained why yours is better than the alternatives. -- 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/9df59e26-2363-4119-9794-090f958c4499%40isocpp.org. ------=_Part_4134_482941154.1531443000458 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thursday, July 12, 2018 at 4:13:56 PM UTC-4, Zhihao Yua= n wrote:
From: Nicol Bolas <= jmck.= ...@gmail.com>=20
Sent: Thursday, July 12, 2018 10:51 AM
>>
>> =C2=A0 =C2=A0 =C2=A0Copyable T;=20
>> =C2=A0 =C2=A0 =C2=A0T x =3D foo();=20
>> =C2=A0 =C2=A0 =C2=A0Copyable x =3D foo();=20
>>
>> strictly speaking, they can coexist.
>=20
> Syntactically speaking, they can coexist. But if a terse syntax pr= oposal is accepted, then your proposal becomes redundant. That is, there= 9;s nothing your proposal can do that a terse one couldn't.

Not redundant comparing to papers other than Herb's,
as others do not introduce a type-name.

=
That's because they don't need to; you can introduce a typenam= e if you want using existing tools.

In order for y= our tool to be superior, you need to explain why:

Concept T;
T var =3D ...;

is bet= ter than

Concept auto var =3D ...;
using T =3D de= cltype(var);

There is no question that they both = accomplish the same end. They both are two lines long.

=
The only difference between them is that... well, in the second case, = the `using` declaration is entirely optional. If you don't need the typ= ename, you don't have to fetch it. In your case, it must be fetched exp= licitly.

You have yet to explain why your method i= s superior.

>> We don't have enough C++20 code to tell whether=20
>> this is a real issue.
>=20
> We don't need C++20 to know whether people frequently need typ= e names for auto-deduced values. We have plenty of experience with `auto` s= ince C++11. And while it certainly does happen, it would be difficult to sa= y that it happens more than 25% of the time you use `auto`.
>=20
> This is especially true if you're among the Almost Always Auto= crowd, since they deduce variables as a matter of course.
>=20
> Also, don't forget that Concepts TS is a real thing with real = users behind it. You could ask them.

No evidence shows that the time we use `auto` is
getting close to the time we constrained-type-specifiers,
there are plenty of cases where constraining is
unnecessary.

Um, if what you're say= ing is true, you do realize that you're arguing against your own= feature, right? Because if people don't want to constrain their deduce= d variables... what do we need your feature for?

I checked text_view's code a= nd had
yet find a use of constrained-type-specifier.

>> =C2=A0I can raise a hypophysis saying=20
>> "repeated constraints happens frequently:"=20
>>
>> =C2=A0 =C2=A0 Iterator T;=20
>> =C2=A0 =C2=A0 T a =3D begin(...);=20
>> =C2=A0 =C2=A0 // ...=20
>> =C2=A0 =C2=A0 T ed =3D find(...);=20
>=20
> But we don't need data, because the alternatives work and don&= #39;t take up more lines of code:
>=20
> Iterator auto a =3D begin(...);
> using T =3D decltype(a);
> // ...
> T ed =3D find(...);

If decltype(a) is acceptable, why we need to
constrain `auto` at all?

The purpose of constraining `auto` deduction is to prevent errors, to veri= fy that the type being used in the expression has the operations that you t= hink it does. The purpose of getting a typename for a variable is to get= its typename.

These are entirely orthogonal a= ctions. One user may want a typename even for an unconstrained deduced vari= able. Another user may not care to get the typename for a constrained deduc= ed variable. Neither feature in any way affects the need for the other.
=

I don't understand what you're getting at with this = question.

> EqualityComparable auto a =3D ..., b =3D ...;
>=20
> Normally, `auto` deduction of multiple variables have to agree in = types, but for constrained deduction, we can allow them to deduce different= types, so long as the constraint has different types to deduce.

That syntax is indistinguishable to

=C2=A0 =C2=A0 Copyable auto a =3D ..., b =3D ...;

Different types, each satisfying Copyable, rather than
satisfying EqualityComparable<decltype(a), decltype(b)>.
=

My point is that your statement that there= 's no way for terse syntax to be used for multiple deductions is incorr= ect. Maybe that particular syntax wouldn't work (though since it's = new syntax, we could require that constrained declarations make the number = of variables match the number of template parameters), but I mentioned othe= r syntaxes that certainly could work.

> My point in bringing that up is that we already have a way to do that.= The idiom is `auto a =3D ...; using T =3D decltype(a);`. That's the id= iom all of the terse syntaxes would use for this too, and therefore they wo= uld be consistent with unconstrained `auto` use.
>=20
> In order to create an equally consistent idiom, you now have to cr= eate an "Any" concept, apply it to a `T`, then use that `T` to &q= uot;constrain" a deduced variable. Why is that better?

There is no such idiom.

I'm not sur= e what you are saying. Are you saying that people who want to deduce a vari= able and access the deduced typename don't use `decltype(variablename)`= to get it? Or that they don't use `using T =3D decltype(variablename)`= to get it? Because the latter is merely a question of whether they need a = shorthand.

And if it is indeed the case that users= usually don't need a shorthand, then your syntax comes up short, since= it requires the creation of that shorthand in order to constrain a variabl= e at all.

If there is then we are wasting
time here, static_assert(Copyable<decltype(it)>) we'are
done.

Everything we're talking about is = syntactic sugar. The effectiveness of syntactic sugar is ultimately based o= n how commonly it will be used, and how much of a pain the alternative is.<= /div>

People want to constrain their variables with conc= epts, and the `static_assert` method is a painful alternative. So we know t= here is a demand for a feature that handles this problem. The question is w= hat the best solution is.

And thus far, you haven&= #39;t explained why yours is better than the alternatives.

--
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/9df59e26-2363-4119-9794-090f958c4499= %40isocpp.org.
------=_Part_4134_482941154.1531443000458-- ------=_Part_4133_152517083.1531443000458-- .