220 39210 <407515e5-f3e4-45e3-969e-733ce4c1f16a@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: itsjimporter@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Using a type alias name in the alias definition? Date: Thu, 19 Jul 2018 11:50:07 -0700 (PDT) Lines: 139 Approved: news@gmane.org Message-ID: <407515e5-f3e4-45e3-969e-733ce4c1f16a@isocpp.org> 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/mixed; boundary="----=_Part_3983_1384000337.1532026207338" X-Trace: blaine.gmane.org 1532026082 26237 195.159.176.226 (19 Jul 2018 18:48:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 19 Jul 2018 18:48:02 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDUNVAVLRYKBBYF2YPNAKGQEKC3HG2Y@isocpp.org Thu Jul 19 20:47:58 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 1fgDy2-0006ic-6k for gclcip-std-proposals@m.gmane.org; Thu, 19 Jul 2018 20:47:58 +0200 Original-Received: by mail-yw0-f199.google.com with SMTP id w190-v6sf4940592ywg.16 for ; Thu, 19 Jul 2018 11:50:09 -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: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=9UEPbTg0+bKNxB3VHVhohK44B47/ZIK3Yty70PAUGGs=; b=IL7539w1a5SSL+ZmSmNYFlIdwEAbEBwdODC7466upPQIR27oHxRTbTpdbqdcIY1rTq oXbTjReDtfHMOoGJ+NhfXymV6OKcUXS0ZCRP3dAwjnmSkAlHbsAkkXwPSUBm9sIFOl0E xz1AbJklu7/YZcsisgNKwtyHKzuNECFTK4IhlYeZyETwFB/KGQ/cteuWBaRh+8CUEE2d G42SUxgce225abNtl3HGvkGZh9jDiJwFrpwE5yLky4DoJCdOA8jqzfIaQam332MAVUh+ TvEqNtxrk8Txx2bznTTE645oGQD8a8QMdtwCPNBBTNFRP6Nsf2osQq64UlU+TXBCl0d0 aKkQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to: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=9UEPbTg0+bKNxB3VHVhohK44B47/ZIK3Yty70PAUGGs=; b=Y5QA8yb4KrxgWiJo+jR+VIAXMNKXJ/EH1lw45cA9AwqHeQxhWnYkBJPhC59ZpsDQwO NkV4BfbaCfN0Ea7euUkkkYWRRuiKqlImu4MlXOp2gnDDs0m19iyO/7VntqmUqHEjRX7r iV+2//cAlmMYoXqzDeTVFf9rPdtasBjK+s9KTddlW/Kl4PSIE+psFqIJ78nkvfjsKDwK nndSS2lWshTgx4HpLGW6UqaAv+IRBaatzcaQrxw+Um6GSd+Isiaxe7+ntO97SJX4Nlzk nqrv/GWyJEaC2XOrAVzslxAJ53fuQiOzCURUpFz3Rw59/JqtWGPy44aRTzElLn39qfMq C64g== 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: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=9UEPbTg0+bKNxB3VHVhohK44B47/ZIK3Yty70PAUGGs=; b=hTygnL9ZMBF6mCxOAF6Inq+OQ8ZJWfWVmZVzYaOooBZRYDf2KAm1QpRGXlPpFs4wsW 6UUbi8rX+RN0NxraO4NebVqM3RWb61ft37TITlH15rZ6q118pxXXtdLHUBxTDZvzR+cr trWcAfsQ9jQO1P8JhaGs0fNH+u6Jm0//nwdwLrj6vNfXI7Hsnc6A/37O8JfTJ+LHApGC 0K/CcoNlekavY/OW1m8U2n8sfsxc5q+n4BbZe0Gb5poyKfxIpasAYn1yz4WQRiGaCDOY JTrexBG9Fh5Fq3RSv+/BzYnVYa5o7/Nuad2rjknbfJFfnwJTJKMAt9HLe9MuqonlS5S5 YlVg== X-Gm-Message-State: AOUpUlFsw2sEjuFo0GIULe8kHn7PNcPWVX6qMTNXG/IfAyjbvRe8AM1o upASN9PWKUsNbdi0zdtdTnijfA== X-Google-Smtp-Source: AAOMgpeuSm5HaZuL7OcyPqrjRfxKDEjTgQRmoZWUOSUEw9YNL90gN0TYNBRg8vHYZUHEX4md68+Mog== X-Received: by 2002:a81:1086:: with SMTP id 128-v6mr3455686ywq.27.1532026208981; Thu, 19 Jul 2018 11:50:08 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:f00f:: with SMTP id p15-v6ls1164935ywm.40.gmail; Thu, 19 Jul 2018 11:50:07 -0700 (PDT) X-Received: by 2002:a0d:de01:: with SMTP id h1-v6mr1093682ywe.3.1532026207802; Thu, 19 Jul 2018 11:50:07 -0700 (PDT) In-Reply-To: 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:39210 Archived-At: ------=_Part_3983_1384000337.1532026207338 Content-Type: multipart/alternative; boundary="----=_Part_3984_26929602.1532026207338" ------=_Part_3984_26929602.1532026207338 Content-Type: text/plain; charset="UTF-8" On Thursday, July 19, 2018 at 6:15:35 AM UTC-7, Dawid Pilarski wrote: > > 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). > Well, consider the sanity check failed. :) I started writing up an argument that perhaps `my_type` on the right should be an invisible "proxy type" to break the recursion, but that adds spooky complexity that I don't think I'd be comfortable with. However, if strong typedefs existed, I could see something like the above being allowed. If a strong typedef created a new type and were roughly equivalent to: struct new_type : base { using base::base; }; Then a strong typedef could use CRTP, making syntax like my suggestion possible: `strong using my_type = foobar` becomes: struct my_type : foobar { using foobar::foobar; }; Still, all that really saves is the `using` directive on the base type's constructor, so I wouldn't consider this a significant motivation for strong typedefs on its own. - 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/407515e5-f3e4-45e3-969e-733ce4c1f16a%40isocpp.org. ------=_Part_3984_26929602.1532026207338 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thursday, July 19, 2018 at 6:15:35 AM UTC-7, Dawid Pila= rski wrote:
Wh= at would that:=C2=A0=C2=A0=C2=A0using=C2=A0my_type=C2=A0=3D=C2=A0<= /span>foobar<my_type>;=C2=A0
mean to you?
If it would be possible, then for the compiler it's infinite recursio= n, so it's not possible (as of my understanding).

Well, consider the sanity check failed. :)
<= br>
I started writing up an argument that perhaps `my_type` on th= e right should be an invisible "proxy type" to break the recursio= n, but that adds spooky complexity that I don't think I'd be comfor= table with. However, if strong typedefs existed, I could see something like= the above being allowed. If a strong typedef created a new type and were r= oughly equivalent to:

struct new_type : base {
=C2=A0 <= /span>using base::base;
};

Then a stron= g typedef could use CRTP, making syntax like my suggestion possible: `stron= g using my_type =3D foobar<my_type>` becomes:

struct my_type : foobar<my_type> {
=C2=A0 using foobar<my_type>::foobar;
};

Still, all that really= saves is the `using` directive on the base type's constructor, so I wo= uldn't consider this a significant motivation for strong typedefs on it= s own.

- Jim

--
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/407515e5-f3e4-45e3-969e-733ce4c1f16a= %40isocpp.org.
------=_Part_3984_26929602.1532026207338-- ------=_Part_3983_1384000337.1532026207338-- .