220 39201 article Path: news.gmane.org!.POSTED!not-for-mail From: Dawid Pilarski Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Using a type alias name in the alias definition? Date: Thu, 19 Jul 2018 15:15:32 +0200 Lines: 198 Approved: news@gmane.org Message-ID: References: <762a20a9-6717-4bf7-b739-21344b173ea2@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000005c113e057159f908" X-Trace: blaine.gmane.org 1532006008 13922 195.159.176.226 (19 Jul 2018 13:13:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 19 Jul 2018 13:13:28 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD6OTSOZVUDBB5M5YLNAKGQEKBUVCWI@isocpp.org Thu Jul 19 15:13:24 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f70.google.com ([209.85.218.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fg8kF-0003Vl-Tb for gclcip-std-proposals@m.gmane.org; Thu, 19 Jul 2018 15:13:24 +0200 Original-Received: by mail-oi0-f70.google.com with SMTP id 20-v6sf3031899ois.21 for ; Thu, 19 Jul 2018 06:15:35 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1532006134; cv=pass; d=google.com; s=arc-20160816; b=o6ySqwjn9qLVFtazQZpQQqFMql3KtfdOwbY3jRGDX3mh9AOOYBkgfhIvIkArL2+mtB YxTu8D+ws41XI02CdFcaGh3U9lCGr1PxZXB9eMs8drubNo03+A/u4PtUXmeE8ZU/cP31 dIpIU4vKN6yM4GNgrc61m0//tfSRaHIMtfYRH4zpCk7g4L+sjTtsOz4jaqF5Kla/Mg1L GGMtcv3l78w0DZmqMRBaf3cWuhMPFQleBu4+0DX/n7m/MBp/IzHpCdVDVJ1eA7TlPpIq RScSRyQ5nzpP6Bfc1gOIQZ1ECXxwpPkWz+oiDeoXoMkMq7fbl9tvuDcJS5bEpQqXuqXc +XHA== 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=i2n2z0etcfOPru3teVpcI4v/71Ce0tatBxf05/3nXHI=; b=KEslsE3vc8XVztUdWqn0Z25QinVKOL8dOJ9BGTpZ/BDOP6b4N12kQD9DOT34BSqIf6 4sKmnSRVlSHKvoh9HCc0+rfYEXNvPMgwGkC9BY0K2pMOA8Vh9KOwGr/ijQhrEoQ7dps0 nda3XCfewsRJsnPyfdSRv7Xwh7g8xbt5QpFb3TGXKUTqv2o6p6bwr09aee62+qBapRHs NKC0uCdOCnTnQ56Ccw5MbwFDnvQuAqiefGqIGYRyQ8W0ZLCiA7aThdMUjLOMffm8NY+w DDIOptA4DFchPg2tGqAcP01f5wjmI8+2OYGteSp0TjamyEOUmAzHtF+O/+/IvsFUKycQ 3sJw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=LKWSl8IQ; spf=pass (google.com: domain of picppstandard@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=picppstandard@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE 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=i2n2z0etcfOPru3teVpcI4v/71Ce0tatBxf05/3nXHI=; b=dBSX0FQYt4EoRpNs4AX4qHnmXohJb+Q7kPtQmpgXjQnE3vH6Hkf1x8eW35z8KwCDOp V+F80QsVaxTr7V7cO16Dg/oyCs0hF+uhCOBupoppE7s/pWy4K0nc+DPwmf7q0oKbo5An /Spelez3EqTDeD5URoXhGmSdx2yWtw7XkWSzUZxe1ltRxGyLUVRv7kvDk4CVsb98Y0eo lkamOmQqiW00xIrPylr8EpR6Y4kBpSALhn5OutwujATQ8jed4ZxMLDQhPS+QiLcQ5Ypj lDsl4FRwAGf7uBJBqVi1ieuqISxa+i49obcCdzXm2g2eEJbRFffdCx7p11Vp1HSxOQ8D YluA== 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=i2n2z0etcfOPru3teVpcI4v/71Ce0tatBxf05/3nXHI=; b=Ckf1vFpabWtG0JgmkP0iTmQbWOS09eTH6uTw/8hRONqZDQGQpqPkFXXm8AxKLaxddA MOrO7V8RKJyInLj4FfRGUg19UjSZwKy4L9QRsKmuLk2bGOvDUxaZGNboPRnjdp7aEYtC bj6QTndK4DUcDwFLBVXzJHJKbpSAoKKhHqDRfwMZ/WwdUAi0298dWymknsMtH9a4IjBj imKJmd6iorxnPHkaAxhcoWNEdbuRbyFA/YjEAjIk1vftrY57K2yAF4wzvC6SiyhHzJcx 7sE86sRekjvlXL6WJN6NPkoE6/+SjiEOti+GPQREYN+vhYxZOqxOOUTK7Ymce8keilOw WmvQ== X-Gm-Message-State: AOUpUlHyf0fNnM5OFPDchNo2fN/rS6+FO/m7N1Z+daZYrQ5rDoH4D9NI wrMU/aC3qiHzSPDKTKGHcNTcWg== X-Google-Smtp-Source: AAOMgpd9BYXIaGnZ+ZXKjcTFZo8Tyq2v0L9aq7UeRsUOysI3EhXJpMEXwoVMwCyy/S2+RLxV2fuD/Q== X-Received: by 2002:aca:b8d5:: with SMTP id i204-v6mr6164916oif.46.1532006134620; Thu, 19 Jul 2018 06:15:34 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:aca:dec3:: with SMTP id v186-v6ls5380772oig.3.gmail; Thu, 19 Jul 2018 06:15:33 -0700 (PDT) X-Received: by 2002:aca:e450:: with SMTP id b77-v6mr11694822oih.0.1532006133496; Thu, 19 Jul 2018 06:15:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532006133; cv=none; d=google.com; s=arc-20160816; b=sBpZ0vEfwLpT+pD6LkhamxUPY2/SbLVrNkod4vYqjUtdNcKVpKjcwESX6593XfiCoe UrzqN/+j+F2hNDvfQuzcwW9+NDIAgL1aeXp6VHZuP5wxFjjvbUK2ZhxGL6RGQjJKS/UA tZHdIzR6YAFNeNi03up3b2BY7aMlH/8dN/v1SvPjXzdFa4xKcfZLwmjFaY1bTYHvFwzS FUnmxZoRoQSkB+r9FM2X8LqHRiI4r2M3zYdc/w1UGyHDTD8fn6CK/BU++MnUhCh/X9AO 054nudzIs32z+V5C30GPW7bRjbS8gun74tCOx50qX7Vr4p9RFql9nRxgUjdHiWObM8zM 1eeg== 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=kXt1DxBM+ws0vyPg/T9uKon5QeOsYW0xahyz1azctT0=; b=H94aOyEa4ekMkmbuOw4bWEccoM5mah+NiGpKWkHGBNqdaMtP2wXz0yM5KXonx9m+AQ 7RYx9KP26BCevBzZrxcKRwR9IFLl3YFW6lyI1nvznDW7A/Xsc7nFDVO8ZULdYZwioUSu V/WBcBvqOLf9aQc3bg8OWUCYNmfRQA1h37mx8Sb6Ap9xB9T1PFUu0l2GUQA5m01Y6d6k FXtrLjCOjo2NIGQvTkuB8OaplOH+WPNS0BaNRmYnXOKhUCFiRVI2Vj96/UtakpXk57kI Mp1u1/G2vZQcKC0D2LbNOW+X7LAK746zj33neymp4E22Pw7EW3210PtXqmAaRb45Tede Z7Tw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=LKWSl8IQ; spf=pass (google.com: domain of picppstandard@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=picppstandard@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE 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 p186-v6sor3490166oia.99.2018.07.19.06.15.33 for (Google Transport Security); Thu, 19 Jul 2018 06:15:33 -0700 (PDT) Received-SPF: pass (google.com: domain of picppstandard@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:aca:edc1:: with SMTP id l184-v6mr10002407oih.65.1532006133140; Thu, 19 Jul 2018 06:15:33 -0700 (PDT) Original-Received: by 2002:a9d:2b1d:0:0:0:0:0 with HTTP; Thu, 19 Jul 2018 06:15:32 -0700 (PDT) In-Reply-To: <762a20a9-6717-4bf7-b739-21344b173ea2@isocpp.org> X-Original-Sender: picppstandard@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=LKWSl8IQ; spf=pass (google.com: domain of picppstandard@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=picppstandard@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE 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:39201 Archived-At: --0000000000005c113e057159f908 Content-Type: text/plain; charset="UTF-8" What would that: using my_type = foobar; mean to you? If it would be possible, then for the compiler it's infinite recursion, so it's not possible (as of my understanding). 2018-07-17 22:22 GMT+02:00 : > (Note: This is just a quick sanity check before I try to write up > something a little more concrete.) Are there any reasons why it would be > impossible to modify the standard to allow using the name of a type alias > in its definition, similar to CRTP? For example: > > using my_type = foobar; > > I ask because this *appears* to be a relatively straightforward way to > handle at least common cases of recursive variants without magic like > Boost's `make_recursive_variant`. For example, you might define a JSON > container like this: > > using json = std::variant< > double, > std::string, > std::vector, > std::map > >; > > (The above would likely also require that `std::map` support values of > incomplete type like `std::vector` already does.) Currently, the only way > around this that I know of is to create one or more subclasses to > forward-declare some of the names as needed. > > - Jim > > > > > > -- > 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/762a20a9-6717-4bf7- > b739-21344b173ea2%40isocpp.org > > . > -- 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/CAJsLGmpMzb7L_Z1yc1gM7ovm2irgERjyWtjcqgjGVHjMBbmZSQ%40mail.gmail.com. --0000000000005c113e057159f908 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What would that:=C2=A0=C2=A0=C2=A0using<= /span>=C2=A0my_type=C2=A0=3D= =C2=A0foobar<my_type>;=C2=A0
mean to= you?

If it would be possible, then for the compiler it's infini= te recursion, so it's not possible (as of my understanding).
<= div class=3D"gmail_extra">
2018-07-17 22:22 G= MT+02:00 <itsjimporter@gmail.com>:
(Note: This is just a quick sanity check be= fore I try to write up something a little more concrete.) Are there any rea= sons why it would be impossible to modify the standard to allow using the n= ame of a type alias in its definition, similar to CRTP? For example:
=C2=A0 using my= _type =3D foobar<my_type>;

I ask because this *appears* to be a relatively = straightforward way to handle at least common cases of recursive variants w= ithout magic like Boost's `make_recursive_variant`. For example, you mi= ght define a JSON container like this:

=C2=A0 using json =3D std= ::variant<
=C2=A0 =C2=A0 double,
=C2=A0 =C2=A0 std::string,
=C2=A0 =C2=A0 std::vect= or<json>,
=C2=A0 =C2=A0 std<= span style=3D"color:#660" class=3D"m_-1490109347464383053styled-by-prettify= ">::map<std::string, json>
=C2=A0 >;<= /span>

(The above would likely also require that `std= ::map` support values of incomplete type like `std::vector` already does.) = Currently, the only way around this that I know of is to create one or more= subclasses to forward-declare some of the names as needed.

- Jim



=C2=A0

--
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/762a= 20a9-6717-4bf7-b739-21344b173ea2%40isocpp.org.

--
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/CAJsLGmpMzb7L_Z1y= c1gM7ovm2irgERjyWtjcqgjGVHjMBbmZSQ%40mail.gmail.com.
--0000000000005c113e057159f908-- .