220 39159 <840eecc5-5aae-40d8-b965-7f74197a3970@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: Concept-defined placeholder type Date: Sat, 14 Jul 2018 00:18:52 -0700 (PDT) Lines: 1538 Approved: news@gmane.org Message-ID: <840eecc5-5aae-40d8-b965-7f74197a3970@isocpp.org> References: <36f3bb9f-ca72-428c-b016-a3c035d657d8@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_129468_57727616.1531552733060" X-Trace: blaine.gmane.org 1531552610 21642 195.159.176.226 (14 Jul 2018 07:16:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 14 Jul 2018 07:16:50 +0000 (UTC) Cc: zy@miator.net, mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBXOHU3NAKGQEMVMOY4I@isocpp.org Sat Jul 14 09:16:45 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f197.google.com ([209.85.213.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1feEnM-0005Wx-LO for gclcip-std-proposals@m.gmane.org; Sat, 14 Jul 2018 09:16:45 +0200 Original-Received: by mail-yb0-f197.google.com with SMTP id x14-v6sf32213540ybj.9 for ; Sat, 14 Jul 2018 00:18:55 -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=MJCJuPphV8gXgUV/kXKQxrFZ4294ZnXQ4D000MALblY=; b=AHR9AXo6XdyxcyURRpbPWPWKXgjh0iBWnYJHqbX8HcDfMICOnw+4CjftaNluF3/Yxs wm2dx3jJMamlpwthBvqwrhSK5Y7WIzrLxys4dnypOIwJJlfeejkHAD7Sh7/SahbXIBDW G6jZ/glPrgdB5Z6o2LUXDrPrYVsfVzsu2G9Gd9eX7YXpCsrFE/B3WGm3dktxpD5UtdO1 AOh/YOYNbxGUqJZGMGzMudvDebTrXPxMzLrkqBd19CIa9zCyP2er5Kd58Rz59gQqQyA8 UTwh/Eozbt3NKKtIQ765Jd1UEs1W/mcxbNCfyNS4uLf7FIA/XuAje6C5cRzuwymVj2BB uZKw== 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=MJCJuPphV8gXgUV/kXKQxrFZ4294ZnXQ4D000MALblY=; b=ecHI9j/QxSPDgN4c57eFnMn4HpBcjHXJ+WoHZ2dPnrc8xKU+kXd4TFwWs7tuSRQT3f PqmbBKhhcJybTvm/IYOT0CVcNP9gOwOBpIUcu/r6ygO7V0jMNsRM5udysJ1D69c4KKbT fdi2KJfAj5nFddxK08+YmwXZv5pld7TpWZvd6O40NRwBm3EmYZuDeRTkLa0u+3Sf/7zV Uy0Mghr8u9E3y5pQgA89Q4qBwJjk5XbW3ep7b4H16LQviCwnnyIDnCOnNSCN1Z48JvTF ANlEStFaNeicYgJSX1gKnVI4QiTmHhT5ICun3qIeWXWQ1iY15RzooZFP6bjVomkapFjt eWEQ== 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=MJCJuPphV8gXgUV/kXKQxrFZ4294ZnXQ4D000MALblY=; b=gLJnOImHjc1wHoVPOpLCoj7YjkhI1vrFyB4kCqTkbI1yBVxwkmZkJoOdtEccJW/ZsE jx6UZ05iC1NM+brv7sfnvY2ZSV8z+lUadH182SW//vAOO6tacdCAF3q0TSGdyhLqz51R lXu9NuzAL71V7dxhm3wh757/6dwVnj0W++JU9tCPbfVyv5gTd9ayCTuelaTUAelit2Nh 3YxVegfygM9JPCOJadWaAsE/9znDw8jC4M30KRkFBSpX7H+Cntog2E5NQNxM8LPqn4fV JKnS3tXsdjpE6FnAVJX0hiAPMI6t5JvCgdbzPVXoR3uIrjXiaR2jCVvpi9peTUxpGbLG vIow== X-Gm-Message-State: AOUpUlFThVmBYdXc8M7XLsOKHaf7LMRgEzGlFEipcX1+2HRQjWbhDlMP wu49GydkbBzLi7AbVaqUpgh7SA== X-Google-Smtp-Source: AAOMgpd2Md/xWuXJpnWJY/kXGuzV+NhjecU+U1bOWREWLKbO8kSzTdr5hAo9NjHoEYrceST+ShPMcg== X-Received: by 2002:a25:9d92:: with SMTP id v18-v6mr2882600ybp.31.1531552735197; Sat, 14 Jul 2018 00:18:55 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:9b97:: with SMTP id s145-v6ls2104964ywg.43.gmail; Sat, 14 Jul 2018 00:18:53 -0700 (PDT) X-Received: by 2002:a81:3807:: with SMTP id f7-v6mr1009594ywa.4.1531552733525; Sat, 14 Jul 2018 00:18:53 -0700 (PDT) In-Reply-To: <36f3bb9f-ca72-428c-b016-a3c035d657d8@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:39159 Archived-At: ------=_Part_129468_57727616.1531552733060 Content-Type: multipart/alternative; boundary="----=_Part_129469_2119421183.1531552733062" ------=_Part_129469_2119421183.1531552733062 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Friday, July 13, 2018 at 10:45:59 AM UTC+3, mihailn...@gmail.com wrote: > > > > On Friday, July 13, 2018 at 1:48:04 AM UTC+3, Zhihao Yuan wrote: >> >> From: mihailn...@gmail.com =20 >> Sent: Thursday, July 12, 2018 4:06 PM=20 >> >>>=20 >> >>> namespace n {=20 >> >>>=20 >> >>> StandardLayoutType T; //< allowed?=20 >> >>>=20 >> >> That's the kind of bug that I'm looking for...=20 >> >> It shouldn't be allowed.=20 >> >=20 >> > Any reason why? Except confusion and probably impl difficulties.=20 >> >> Let's say you have this declaration in a header and include=20 >> it in two different translation units, then essentially you=20 >> got a "poor man's namespace template." The outcome of=20 >> enforcing T to be deduced to the same type across=20 >> translation units isn't useful enough to justify its complexity.=20 >> >> I think these declarations should appear only in block scopes,=20 >> and have no linkage, as same as constrained-parameters.=20 >> > > Hum, the way I see it the type must be the same only in a given template= =20 > instantiation not across all instantiations > > namespace a { > > Number Num; > > template > auto func() > { > Num n =3D S.do(); > > Num p =3D . . .; > > // Num will be the same for func, lets say an int > } > > template > auto func() > { > Num n =3D S.do(); > > // Num will be the same for func - a float=20 > } > }//< a > > // other TU > > #include > > namespace b { > > template > auto func() > { > a::Num n =3D S.do(); > > // a::Num will be short > } > > }//< b > > I don't think it is good idea, but I don't see much of a problem. > > Now, if=20 > > namespace a { > > Number Num; > const N var =3D 1; > > }// > and > > #include > > namespace a { > const N var2 =3D "string"; > } > > or > > namespace b { > const a::N var =3D "string"; > } > > Will fail - N is an int. > > The point is - the name can cross scopes, much like always, bounding=20 > (template instantiation) can't=20 > That is the same as in the constexpr if case in local scope - same name= =20 > different instantiations, different bounding=20 > > > > Of course none of this is recommended practice, much like global variable= s=20 > are bad > > For example > > namespace a { > > Number Num; > > }// =20 > namespace b { > const a::N bvar =3D 1; > } > > now, if we include a file that > > namespace a { > > const a::N somevar =3D 1.f; > > }// > BEFORE b, then we "silently" change bvar to float > > > This is one of the reasons I prefer to *not* let late bounding *just yet*= .. > > I see no material benefit, yet multiple issues. > > I am ok with Number auto > > And I hope it will be upgraded to Number T as it *dramatically* improves= =20 > declarations as one sees a type like he always did, granted not a concret= e=20 > one > > [](All Args&&... args) { f(std::forward(args)...); } > > *I will take that before ANY other form!* > > > Oh, boy, *I just remembered*: using Randon_access_iterator{Ran};=20 // ...=20 void sort(Ran p, Ran q); using Forward_iterator{For}; using Forward_iterator{For2};=20 using Output_iterator{Out};=20 // ...=20 void merge(For p, For q, For2 p2, For2 q2, Out p); The syntax of this using-declaration is: using name-of-concept {=20 identifier-list };=20 So, we have a very terse syntax that minimizes repetition and can=20 distinguish between two uses of the same type of a concept and=20 (potentially) two di=EF=AC=80erent type of a concept.=20 In case, you lost track of the reason for going in this direction: This=20 terse syntax can be used for lambdas, where the old (verbose) syntax is=20 either impossible or so verbose that it would encourage the use of=20 unconstrained lambdas. For example:=20 [] (For p, For q, For2 p2, For2 q2, Out p) { /=E2=88=97 do some merging ...= =E2=88=97/ } *It is from:*=20 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3580.pdf *Sound familiar? :)* --=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/840eecc5-5aae-40d8-b965-7f74197a3970%40isocpp.or= g. ------=_Part_129469_2119421183.1531552733062 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Friday, July 13, 2018 at 10:45:59 AM UTC+3, mih= ailn...@gmail.com wrote:


On Friday, July 13, 2018 at 1:48:04 AM UTC+3, Zhihao Yua= n wrote:
From: m= ihailn...@gmail.com <mihailn...@gmail.com>= ;=20
Sent: Thursday, July 12, 2018 4:06 PM
>>>=20
>>> namespace n {=20
>>>=20
>>> StandardLayoutType T; //< allowed?=20
>>>=20
>> That's the kind of bug that I'm looking for...=20
>> It shouldn't be allowed.=20
>=20
> Any reason why? Except confusion and probably impl difficulties.

Let's say you have this declaration in a header and include
it in two different translation units, then essentially you
got a "poor man's namespace template." The outcome of
enforcing T to be deduced to the same type across
translation units isn't useful enough to justify its complexity.

I think these declarations should appear only in block scopes,
and have no linkage, as same as constrained-parameters.

Hum, the way I see it the type must be= the same only in a given template instantiation not across all=C2=A0=C2=A0= instantiati= ons

namespace a {

Number Num;
=

template<Something S>
auto func()=
{
= =C2=A0 Num n =3D S.do();

<= div>=C2=A0 Num p =3D . . .;

=C2=A0 // Num will be the same= for func, lets say an int
}

template<SomethingElse S>=
auto= func()
{
=C2=A0 Num n =3D S.do();

=C2=A0 // Num will be the s= ame for func - a float=C2=A0
}
}//< a
<= /b>
// other TU

#include <a.h>

namespac= e b {

template<Something S>
auto func()
{
=C2=A0 a::Num n =3D S.do();

=C2=A0 // a::Num will be short
}

}//< b

I don't think it is goo= d idea, but I don't see much of a problem.

Now, if=C2=A0

= namespace a {

Number Num;
const N var =3D 1;
<= span style=3D"text-align:left;color:rgb(34,34,34);text-transform:none;text-= indent:0px;letter-spacing:normal;font-size:13px;font-style:normal;font-vari= ant:normal;font-weight:400;text-decoration:none;word-spacing:0px;display:in= line!important;white-space:normal;float:none;background-color:transparent">= <= /sup>
}//<a

and=

#include <a.h>

namespace a {
const N var= 2 =3D "string";
}

or

namespace b {
const a::N var =3D "string";
}=

Will fail - N is an int.

The p= oint is - the name can cross scopes, much like always, bounding (template i= nstantiation) can't=C2=A0
That is the same as in the constexp= r if case in local scope - same name different instantiations, different bo= unding=C2=A0



Of cour= se none of this is recommended practice, much like global variables are bad=

For example

<= font face=3D"courier new,monospace" style=3D"border-bottom-color:rgb(34,34,= 34);border-bottom-style:none;border-bottom-width:0px;border-left-color:rgb(= 34,34,34);border-left-style:none;border-left-width:0px;border-right-color:r= gb(34,34,34);border-right-style:none;border-right-width:0px;border-top-colo= r:rgb(34,34,34);border-top-style:none;border-top-width:0px;margin-bottom:0p= x;margin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;paddin= g-left:0px;padding-right:0px;padding-top:0px">namespace a {

Number Num;

}//<a
<= /div>
=C2=A0
namespace b {
const a::N bvar =3D 1;
}<= /div>
=
now, if we include a file that

namespa= ce a {

const a::N somevar =3D 1.f;
=
<= /font>
}//<a

=
BEF= ORE b, then we "silently" change bvar to float

=
This is one = of the reasons I prefer to not let late bounding just yet.

I see no material benefit, yet multiple = issues.

I am ok with Number auto

And I hope it will b= e upgraded to Number T as it dramatically improves declarations as one sees a type like he always d= id, granted not a concrete one

[](All Args&&... args) {= f(std::forward<Args>(args)...); }

I will take that before ANY other form!

=



Oh, b= oy, I just remembered:
using Randon_a= ccess_iterator{Ran};=C2=A0

// ...=C2= =A0

=
void sort(Ran p, Ran q);

using Forward_iterator{For};
=
using Forward_iterator{For2};=C2= =A0
using Output_iter= ator{Out};=C2=A0

=
// ...=C2=A0<= /div>

void merge(For p, For q, For2 p2, For2 q2, O= ut p);

The syntax of this using-declaration is:= using name-of-concept { identifier-li= st };=C2=A0

So, we have a very terse syn= tax that minimizes repetition and can distinguish between two uses of the s= ame type of a concept and (potentially) two di=EF=AC=80erent type of a conc= ept.=C2=A0
In case, you lo= st track of the reason for going in this direction: This terse syntax can b= e used for lambdas, where the old (verbose) syntax is either impossible or = so verbose that it would encourage the use of unconstrained lambdas.=

For example:=C2=A0
[] (For p, For q, For2 p2, For2 q2, Out p) { /=E2=88=97= do some merging ... =E2=88=97/ }


It is from: http://www.open-std.org/jtc1/sc22= /wg21/docs/papers/2013/n3580.pdf


Sound familiar? :)

--
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/840eecc5-5aae-40d8-b965-7f74197a3970= %40isocpp.org.
------=_Part_129469_2119421183.1531552733062-- ------=_Part_129468_57727616.1531552733060-- .