220 39138 <36f3bb9f-ca72-428c-b016-a3c035d657d8@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: Fri, 13 Jul 2018 00:45:59 -0700 (PDT) Lines: 2463 Approved: news@gmane.org Message-ID: <36f3bb9f-ca72-428c-b016-a3c035d657d8@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_37140_1888108935.1531467959176" X-Trace: blaine.gmane.org 1531467840 2040 195.159.176.226 (13 Jul 2018 07:44:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 13 Jul 2018 07:44:00 +0000 (UTC) Cc: zy@miator.net To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBOFRUHNAKGQEBRTWZVY@isocpp.org Fri Jul 13 09:43:55 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f198.google.com ([209.85.161.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fdsk2-0000HL-Lf for gclcip-std-proposals@m.gmane.org; Fri, 13 Jul 2018 09:43:51 +0200 Original-Received: by mail-yw0-f198.google.com with SMTP id c204-v6sf24455934ywa.8 for ; Fri, 13 Jul 2018 00:46:01 -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=u8xtulGCZd0/WXwf/99itu4H4/eHyj+UPGECxWmToYY=; b=eaXfHGfzUvxvjZ2+kyhFPtUzqp83+hRtmapcBNsyktIShZkXluQ8iWbejOeyu4tUS9 QKrjNhVAp39TuKjJr+ZxeiU7UFOvLsJ20neyS0iPkCUCQOaTfAu9wFDK6tAs100JA+kt R7HmuuGFTwv+CjnTgBG7yc8iZ53ZPqC06tL6frHA5l70Q+6Ypbz/gJBwfcFk3spBw/0G GZoKArYtHZIDxYgQIDXIAvME71w0PD5dv1zOdMGtfoQhs+gNmL67+jAEntvtr4BpQyz4 xcicu8+FZL2V2svHKyKUQqGvXp5Mbw3fWJKvaY2Sxsq3rYoIfi5I3q27iaK3lh5oA8Zo MHPg== 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=u8xtulGCZd0/WXwf/99itu4H4/eHyj+UPGECxWmToYY=; b=Y/qFbmT7RrUHCH2mV3Losc7un3nTuotc9sz8yKoLY4UKVT8KnMXrv0hzQbGFHrOe3J WgZU1K3yfbCEXmF/4hXCSPMp25MfrypBjYZW+k1vTE/e2M5aEQnEij86HoAvju6isQ4/ DaoVH90AhJD/8YrTsl6Y9kbfrhO2VGUTliZFpkVzyywKsNYkNZ2/vTRwBh53LSIUpy/M e5BeNBY5ZiyRoJ3gQHKJXcPco2CTdom85betxbPCzVScdNUlx6+es6H0z56u20UvtItY sD274u0w/8Itpc7Uji4iyQwp/tA3Jqfd+bikjWGFrntFjcb/8r7PXVb1Ia6zhIiVwY7R R6Rg== 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=u8xtulGCZd0/WXwf/99itu4H4/eHyj+UPGECxWmToYY=; b=K8cfpwOn2RXHn7D/8CAU8JkjlHiz09wUFtS+QD3tVgV+0yf9a+NX1nbX/eri/frvYH 3eGy8BFIBjumz+QJPor7qTS+oe0EiKsT94XdX2fTCei4pv1v7q/pSLU/yNgYZUBpjTZZ dt4jqAPvITtDXUoFaZszC0vnp34O1/O3Ne5RN5mkdLr7OCeou/Td4PTzzQZwLevMvjc4 IcQBHvJbun220Wx80s9UkH3zqqIM5IdqWcp6btC8n85pKk7csRNX1M0kIEBOLU98DUfn ylEUKESiT9Tv/RCMMqOLc4y4nDIIXl6BgB2rCa5k/Iqt4I333Dq+mOKpldQ11ge+2fze Q8Xw== X-Gm-Message-State: AOUpUlGPBq8+BtnhW/mrKl3xGA87qlslIYvYuoNJHJS/mgbVeH4zKYim r/OBDtlGrrGNmPmLXUKmYGlslg== X-Google-Smtp-Source: AAOMgpdgoTCvPfq78CU10y5Y2N5aqkkbuqwtTLAHxrpSNrvFvR4B7oolTLkzGxQYpx4ssxYPxdSkgA== X-Received: by 2002:a81:e905:: with SMTP id d5-v6mr1603188ywm.31.1531467961281; Fri, 13 Jul 2018 00:46:01 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:814e:: with SMTP id j14-v6ls6538335ybm.3.gmail; Fri, 13 Jul 2018 00:46:00 -0700 (PDT) X-Received: by 2002:a5b:349:: with SMTP id q9-v6mr528763ybp.7.1531467959741; Fri, 13 Jul 2018 00:45:59 -0700 (PDT) In-Reply-To: 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:39138 Archived-At: ------=_Part_37140_1888108935.1531467959176 Content-Type: multipart/alternative; boundary="----=_Part_37141_50913461.1531467959179" ------=_Part_37141_50913461.1531467959179 Content-Type: text/plain; charset="UTF-8" On Friday, July 13, 2018 at 1:48:04 AM UTC+3, Zhihao Yuan wrote: > > From: mihailn...@gmail.com > > Sent: Thursday, July 12, 2018 4:06 PM > >>> > >>> namespace n { > >>> > >>> StandardLayoutType T; //< allowed? > >>> > >> That's the kind of bug that I'm looking for... > >> It shouldn't be allowed. > > > > 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 instantiations namespace a { Number Num; template auto func() { Num n = S.do(); Num p = . . .; // Num will be the same for func, lets say an int } template auto func() { Num n = S.do(); // Num will be the same for func - a float } }//< a // other TU #include namespace b { template auto func() { a::Num n = 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 namespace a { Number Num; const N var = 1; }// namespace a { const N var2 = "string"; } or namespace b { const a::N var = "string"; } Will fail - N is an int. The point is - the name can cross scopes, much like always, bounding (template instantiation) can't That is the same as in the constexpr if case in local scope - same name different instantiations, different bounding Of course none of this is recommended practice, much like global variables are bad For example namespace a { Number Num; }//(args)...); } *I will take that before ANY other form!* -- 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/36f3bb9f-ca72-428c-b016-a3c035d657d8%40isocpp.org. ------=_Part_37141_50913461.1531467959179 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Friday, July 13, 2018 at 1:48:04 AM UTC+3, Zhih= ao Yuan wrote:
From: mihailn...@gmai= l.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= instant= iations
namespace a {

Number Num;<= /span>

=
template<Something S&= gt;
auto fu= nc()
{
=C2=A0 Num n = =3D S.do();

=C2= =A0 Num p =3D . . .;

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

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

=C2=A0 // Num will be the same for func - a float=C2=A0
}
= = }//< a

// o= ther TU

#include <a.h>

namespace 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 th= ink it is good idea, but I don't see much of a problem.

Now= , if=C2=A0

namespace a {

Number = Num;
const N var =3D 1= ;

}//<a
<= font face=3D"courier new,monospace">
and

=
#include <a.h>

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

or

namespace b {
const a::N var =3D "str= ing";
}
<= div>Will fail - N is an int.

The point is - the na= me can cross scopes, much like always, bounding (template instantiation) ca= n't=C2=A0
That is the same as in the constexpr if case in loc= al scope - same name different instantiations, different bounding=C2=A0



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

<= /div>
For example

namespa= ce a {

Number Num;

<= div style=3D"background-color: transparent; border-bottom-color: rgb(34, 34= , 34); border-bottom-style: none; border-bottom-width: 0px; border-image-ou= tset: 0; border-image-repeat: stretch; border-image-slice: 100%; border-ima= ge-source: none; border-image-width: 1; border-left-color: rgb(34, 34, 34);= border-left-style: none; border-left-width: 0px; border-right-color: rgb(3= 4, 34, 34); border-right-style: none; border-right-width: 0px; border-top-c= olor: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; color= : rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helveti= ca&quot;,sans-serif; font-size: 13px; font-style: normal; font-variant:= normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; marg= in-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-botto= m: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align= : left; text-decoration: none; text-indent: 0px; text-transform: none; -web= kit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">}//<a
=C2=A0
namespace = b {
const a::N bvar =3D 1;
=
}

now, if we include a file that

<= font face=3D"courier new,monospace" style=3D"border-bottom-color: rgb(34, 3= 4, 34); border-bottom-style: none; border-bottom-width: 0px; border-image-o= utset: 0; border-image-repeat: stretch; border-image-slice: 100%; border-im= age-source: none; border-image-width: 1; border-left-color: rgb(34, 34, 34)= ; border-left-style: none; border-left-width: 0px; border-right-color: rgb(= 34, 34, 34); border-right-style: none; border-right-width: 0px; border-top-= color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; marg= in-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; paddi= ng-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">n= amespace a {

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

<= span style=3D"background-color: transparent; border-bottom-color: rgb(34, 3= 4, 34); border-bottom-style: none; border-bottom-width: 0px; border-image-o= utset: 0; border-image-repeat: stretch; border-image-slice: 100%; border-im= age-source: none; border-image-width: 1; border-left-color: rgb(34, 34, 34)= ; border-left-style: none; border-left-width: 0px; border-right-color: rgb(= 34, 34, 34); border-right-style: none; border-right-width: 0px; border-top-= color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; colo= r: rgb(34, 34, 34); display: inline; float: none; font-size: 13px; font-sty= le: normal; font-variant: normal; font-weight: 400; letter-spacing: normal;= margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; = orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; pad= ding-top: 0px; text-align: left; text-decoration: none; text-indent: 0px; t= ext-transform: none; -webkit-text-stroke-width: 0px; white-space: normal; w= ord-spacing: 0px;">BEFORE b, then we "silently" change bvar to = = float

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

I see no material benefit, yet mult= iple issues.

I am ok wit= h Number auto

And I hope it will be upgraded to = Number T as it dramatically<= /i> improves declarations as one sees a type like he always did, granted no= t a concrete one

[](All = Args&&... args) { f(std::forward<Args>(args)...); }
<= span style=3D"background-color: transparent; border-bottom-color: rgb(34, 3= 4, 34); border-bottom-style: none; border-bottom-width: 0px; border-image-o= utset: 0; border-image-repeat: stretch; border-image-slice: 100%; border-im= age-source: none; border-image-width: 1; border-left-color: rgb(34, 34, 34)= ; border-left-style: none; border-left-width: 0px; border-right-color: rgb(= 34, 34, 34); border-right-style: none; border-right-width: 0px; border-top-= color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; colo= r: rgb(34, 34, 34); display: inline; float: none; font-size: 13px; font-sty= le: normal; font-variant: normal; font-weight: 400; letter-spacing: normal;= margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; = orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; pad= ding-top: 0px; text-align: left; text-decoration: none; text-indent: 0px; t= ext-transform: none; -webkit-text-stroke-width: 0px; white-space: normal; w= ord-spacing: 0px;">
I will take that before ANY other for= m!


<= /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/36f3bb9f-ca72-428c-b016-a3c035d657d8= %40isocpp.org.
------=_Part_37141_50913461.1531467959179-- ------=_Part_37140_1888108935.1531467959176-- .