220 39186 <762a20a9-6717-4bf7-b739-21344b173ea2@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: itsjimporter@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Using a type alias name in the alias definition? Date: Tue, 17 Jul 2018 13:22:34 -0700 (PDT) Lines: 124 Approved: news@gmane.org Message-ID: <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/mixed; boundary="----=_Part_26284_385720724.1531858954613" X-Trace: blaine.gmane.org 1531858829 28890 195.159.176.226 (17 Jul 2018 20:20:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 17 Jul 2018 20:20:29 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDUNVAVLRYKBBC5AXHNAKGQED7XFNSY@isocpp.org Tue Jul 17 22:20:25 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 1ffWSP-0007Pg-E6 for gclcip-std-proposals@m.gmane.org; Tue, 17 Jul 2018 22:20:25 +0200 Original-Received: by mail-yb0-f200.google.com with SMTP id p4-v6sf1188250ybk.6 for ; Tue, 17 Jul 2018 13:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=xHPxRtpRb2TepBgPWNWZlILhXYiJMlxEVkEPYpwO14o=; b=Oz8rowP6TfH3f9n90SIjKEP37PR0SJMVWbWDSCzc3l3ohw9xteCFlMvVH/dt0vxzru JTbMF9bJp8q6QdOOWKZhzYFZPcxqyFgws2JxjKPHCrrugyxGb0w7yoGtIE9aaReHM3JM bdSDyUaCLt/77twEqjcw89OKLaWchZXQOiDHpeimOuCWtNNc3v6Rc4qbjIk86IXN2wQD FXbIMQWlEOoCJMo1X7h6kxNzhu6QLyVFDs+7XKUw2jdm4PH89nclIdKzeASaUL7MC/K5 YuDe6BjM0qwkwg0m6uGpzrv/6qVW1EWH8FqwaO77ARnyOusa9xl2pud1tzKDhGC7aTnA faSQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=xHPxRtpRb2TepBgPWNWZlILhXYiJMlxEVkEPYpwO14o=; b=KsnvDbp27MybwLK2uI6veVfmEiAIReJiiC8N8swVT82Mpmbc8MLNu3oWnVX1b4kaDO iyEGJ5zXlk2bQuOEOqc8sZPQiYAySe7vWHHutC9Grb98qYoCLXkySmQSOd1E5PYnjruN OOoolLaeBodpa3tH0KxSSXkPkqZPX99bDSUJwj+NjSES54Llx4lSuxBSPgchNpboVoE9 cH42E5kqFYog1QurgFRwOCezIvjSaXJvGnWZWGbwTxcmwuYKOoFGX85VC4MH+Vcu5Y/p gsjoqidY9udbOut5aLlLxGtX7YCshrzrCujdYSJ9b86NU23GFKBc7LHTQVNWIPjzdg1a dfGQ== 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:message-id: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=xHPxRtpRb2TepBgPWNWZlILhXYiJMlxEVkEPYpwO14o=; b=E/LjTY79WDnHPSf3miJO5Wy6tgv33pNTQC2Jeu3DJKUOGD/4hHGDdG7VN4Qumc2LRh CP6lJZKM/8qQFDaQAg1gLnWaWuS3n2VKmHL8fYkKZceYtHlBf5m5e/YzdAc+hCd6uqLY 4JqDL5zVQrOpnWWwo8LfuvSNfxPgzVhrhEhGGsbbd4gbiHb9VRX9Mx7SfthmOd2RgJg1 cRBTFWktT/ByaXd0IAWZdDqd2U1GsrgnDzXjQSexMp1z84AmBWOPid0toL25jxwb7Ake l7nG0FP+3O4h8c99V4yMd16Nk3Ot2gykuow2u6OlrfGEEoLrZvAYU+2o4LtclmAA2tpJ xtng== X-Gm-Message-State: AOUpUlHLhPwqVlYlE6BW/MpUTVwML7v/n/wtZZKdaeMUmrElmlFqeAPA fnHtDU+uZWfrTAGqp8Tp0An2Fw== X-Google-Smtp-Source: AAOMgpe4goeL9OcdVAKo+wbY5xqoN5COz8n5A6Ya1eytaUCmtSXRW08u/lp9+kasT9Cxx2nOqckSyQ== X-Received: by 2002:a5b:3cf:: with SMTP id t15-v6mr906692ybp.10.1531858956029; Tue, 17 Jul 2018 13:22:36 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a5b:2c3:: with SMTP id h3-v6ls598577ybp.19.gmail; Tue, 17 Jul 2018 13:22:35 -0700 (PDT) X-Received: by 2002:a25:5f4a:: with SMTP id h10-v6mr373930ybm.5.1531858954934; Tue, 17 Jul 2018 13:22:34 -0700 (PDT) X-Original-Sender: itsjimporter@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:39186 Archived-At: ------=_Part_26284_385720724.1531858954613 Content-Type: multipart/alternative; boundary="----=_Part_26285_1102741222.1531858954613" ------=_Part_26285_1102741222.1531858954613 Content-Type: text/plain; charset="UTF-8" (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. ------=_Part_26285_1102741222.1531858954613 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Note: This is just a quick sanity check before I try to w= rite up something a little more concrete.) Are there any reasons why it wou= ld be impossible to modify the standard to allow using the name of a type a= lias 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 without magic like Boost's= `make_recursive_variant`. For example, you might define a JSON container l= ike this:

=C2=A0 using json =3D= std::variant<
=C2=A0 =C2=A0 double,
=C2=A0 =C2=A0 std::string,
=C2=A0 =C2=A0 std::vector<json>,
=C2=A0 =C2=A0 std::map<std::stri= ng,= json>
=C2=A0 >;

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

- Jim



=C2=A0 <= br>

--
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/762a20a9-6717-4bf7-b739-21344b173ea2= %40isocpp.org.
------=_Part_26285_1102741222.1531858954613-- ------=_Part_26284_385720724.1531858954613-- .