220 39030 <120f7272-55aa-4796-910d-6a3c3cd3504e@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Alberto Barbati Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Concepts: Investigating implicit type-name introduction Date: Mon, 9 Jul 2018 04:11:29 -0700 (PDT) Lines: 127 Approved: news@gmane.org Message-ID: <120f7272-55aa-4796-910d-6a3c3cd3504e@isocpp.org> References: <0c0da3b7-02f4-4130-9441-5a1385864d39@isocpp.org> <07ec2785-ec90-4b72-bdbe-3cf624eac38b@isocpp.org> <77785201-b43f-4369-89d6-c8a6290f3532@isocpp.org> <340d7333-282f-4b54-bb43-bed735371c30@isocpp.org> <6b657f87-26ba-46a4-a378-3d4fab46d4db@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_39533_1170181255.1531134689328" X-Trace: blaine.gmane.org 1531134565 24495 195.159.176.226 (9 Jul 2018 11:09:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 9 Jul 2018 11:09:25 +0000 (UTC) Cc: jmckesson@gmail.com, zy@miator.net, mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCPY5DV6RIMBBYUFRXNAKGQEWBFNLOA@isocpp.org Mon Jul 09 13:09:20 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f200.google.com ([209.85.161.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fcU2i-0006HT-89 for gclcip-std-proposals@m.gmane.org; Mon, 09 Jul 2018 13:09:20 +0200 Original-Received: by mail-yw0-f200.google.com with SMTP id p11-v6sf19201112ywm.4 for ; Mon, 09 Jul 2018 04:11:31 -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=UhTXkMcQd6b6E9pLWw72hZ/o96+LfWj0ZJe8YSZp82U=; b=NGydZzhGgdDMKxNWKeV4S35JkAa+y6cUR7paEW2E/ujYjzSNnYGP+XF5ojjD4i8DWv +HgMYTER7FYZ3sF/z3/u5pose0I3t9zZVIfj9ThA1wDTeS97B4q247YQGtSARXcDjqqV AftDGGM2tejH1DJYefStMVpN4HyGSqH1JzYegywoHl8UNBSAdIUqBr1YsImFlI0BF+Ob vv3RDIgZOJWwhYKZVKsz2Rl/z6gtcrbCiy3TeeNnyJzYF4jwaFAVl0Z9XSlK59gX6Cra YGIoGCuixC0DAC6c6Joz+UnF56pYEPuQ2F5BITasWDdI2TZBoEwO7h1KhJZ5AlaxeCME zXcw== 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=UhTXkMcQd6b6E9pLWw72hZ/o96+LfWj0ZJe8YSZp82U=; b=qNT8grXULB5W66MV5K2CDOJx48HhQVPlAYSfG1FXEinHeEusNVM/6wL8+JCJm5gcNZ FE7QbbIcybVcOHclAqi/0LcdHbziGr/Ih2cgo+Qxy7qeVQcwSZNy4FciPy2wQiXix3Gt ANvpXM1oWPYlzTTd6wKHMucxUdLDbpb6g66o7kqMlRJzmwwudPCYy5LASf3lZYYkkIGe Xtq2gkKm/++CsA00nbysYg/TTlXN9xUPudD7bqggEmyKR+1PWmGbtNoxsWnGCCOO5sxZ WqAvA6s8C3Dd1iGm9sAYw8i9rlTK1iUd4PF6fdWyJAbQqR+WjGiwG8esG6UMXO9OI2aO pakw== 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=UhTXkMcQd6b6E9pLWw72hZ/o96+LfWj0ZJe8YSZp82U=; b=LSrYPSByXNN8ZKteF+nzNu+FN3KWLiaQQaHW73ViE3fQWGYjeHlLXHB0XBACQGg+ro UWUxoO7Y5KH1RqrWWcXJeiXGKDwHYLQwKTfenrFKIUGzjeB6KtG+VVOWlS20VEOLJS8G 6asZcb2P2jf5BvlJsY6lowRel+u7Hhu6BQIaeXEfiPO23xtEj0P4Au4ebx0OnRzo2GLc wSAwqjsRCtIe/+aBQitoA/jvpKAD2iV0fu2RQTHPx4Ua8BDSMlxMRakyeuJLlok1qcce xBRV4LR1QVXmJAciXWynW+wJFktwDFxhgop0SYWpqv/M5Izc5h/tvEV5Q8vTtXBpr1k+ nu+w== X-Gm-Message-State: APt69E2yiAWa/VfgWWDXklJ19zb9jBuDW6CXw12cKXSO8m3nsth5XteE tDzK0M/7KE6AcovC4K3rjg3JBA== X-Google-Smtp-Source: AAOMgpcGJ4JqNUH5+tnuc/qQqqmumK+9OWItOWxFSoOT2fVI4NOH8hD+DQWy54YnsOcAy4/MRcD9HQ== X-Received: by 2002:a81:2304:: with SMTP id j4-v6mr6012562ywj.101.1531134691138; Mon, 09 Jul 2018 04:11:31 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:4706:: with SMTP id u6-v6ls417477ywa.1.gmail; Mon, 09 Jul 2018 04:11:30 -0700 (PDT) X-Received: by 2002:a81:78c6:: with SMTP id t189-v6mr2711785ywc.7.1531134690024; Mon, 09 Jul 2018 04:11:30 -0700 (PDT) In-Reply-To: <6b657f87-26ba-46a4-a378-3d4fab46d4db@isocpp.org> X-Original-Sender: AlbertoBarbati@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:39030 Archived-At: ------=_Part_39533_1170181255.1531134689328 Content-Type: multipart/alternative; boundary="----=_Part_39534_890489627.1531134689328" ------=_Part_39534_890489627.1531134689328 Content-Type: text/plain; charset="UTF-8" Let's start by saying that I like P1141. I believe that some of the objections I saw in this thread are due to the attempt of using an approach that worked for some of the previously proposed syntaxes. However, I believe the syntax proposed in P1141 and, in particular, the consistent of "auto", allows for a completely different approach, that not only addresses most use-cases but also allows new programming techniques. Allow me to explain my idea that I call "placeholder type alias". The idea is simple: in every place I can write auto, I can write auto{Type} and have Type being defined as an alias of whatever type has been deduced by auto. This means: In templates: void f(auto{T} x) // equivalent to template void f(T x); void f(auto{T} x, T y) // equivalent to template void f(T x, T y) void f(const auto{T}& x) // equivalent to template void f(const T& x) void advance(auto{I}& i, difference_type_t n); template void f(); // T is an alias for decltype(N) template requires /* complex constraint involving T */ void f(); In variable declarations: auto{T} x = f(); // T is alias for decltype(x) In return value: auto{Result} f() -> /* complex type declarator */; // Result is an alias for complex type declarator in this case, Result would be declared right after the trailing-return-type, so it is avaiable in the requires-clause of the function, as well as inside the function body. We should require a trailing-return-type, though, to avoid getting into a catch-22 situation where the type-alias deduction depends on the type-alias itself. In operators: operator Sortable auto{Result}() { /* Result is an alias of the return type */ } With the same rationale of P1141 I would leave structured bindings alone. The same syntax could be extended to decltype(auto), where applicable. Comments? -- 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/120f7272-55aa-4796-910d-6a3c3cd3504e%40isocpp.org. ------=_Part_39534_890489627.1531134689328 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Let's start by saying that I like P114= 1. I believe that some of the objections I saw in this thread are due to th= e attempt of using an approach that worked for some of the previously propo= sed syntaxes. However, I believe the syntax proposed in P1141 and, in parti= cular, the consistent of "auto", allows for a completely differen= t approach, that not only addresses most use-cases but also allows new prog= ramming techniques. Allow me to explain my idea that I call "placehold= er type alias". The idea is simple: in every place I can write auto, I= can write auto{Type} and have Type being defined as an alias of whatever t= ype has been deduced by auto. This means:

In templ= ates:

=C2=A0=C2=A0=C2=A0 void f(auto{T} x) // equi= valent to template <class T> void f(T x);

=C2=A0=C2=A0=C2=A0 void f(auto{T} x, T y) // equivalent to template <= class T> void f(T x, T y)

=C2=A0=C2=A0=C2= =A0 void f(const auto{T}& x) // equivalent to template <class T> = void f(const T& x)

=C2=A0=C2=A0=C2=A0 void adv= ance(auto{I}& i, difference_type_t<I> n);

=C2=A0=C2=A0=C2=A0 template <Constraint auto{T} N> void f(); /= / T is an alias for decltype(N)

=C2=A0=C2= =A0=C2=A0 template <auto{T} N> requires /* complex constraint involvi= ng T */ void f();

In variable decl= arations:

=C2=A0=C2=A0 auto{T} x =3D f(); // T is alias f= or decltype(x)

In return value:

=C2=A0=C2=A0 auto{Result} f() -> /* complex type declarator = */; // Result is an alias for complex type declarator

<= div>in this case, Result would be declared right after the trailing-return-= type, so it is avaiable in the requires-clause of the function, as well as = inside the function body. We should require a trailing-return-type, though,= to avoid getting into a catch-22 situation where the type-alias deduction = depends on the type-alias itself.

In operators:

=C2=A0=C2=A0=C2=A0 operator Sortable auto{Result}() = { /* Result is an alias of the return type */ }

Wi= th the same rationale of P1141 I would leave structured bindings alone. The= same syntax could be extended to decltype(auto), where applicable.

Comments?

--
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/120f7272-55aa-4796-910d-6a3c3cd3504e= %40isocpp.org.
------=_Part_39534_890489627.1531134689328-- ------=_Part_39533_1170181255.1531134689328-- .