------=_Part_344_2112699798.1538143682717
Content-Type: multipart/alternative;
 boundary="----=_Part_345_21275312.1538143682718"

------=_Part_345_21275312.1538143682718
Content-Type: text/plain; charset="UTF-8"

*The Problem*

Currently, we are not able to refer to a type in its template. For example,
it is impossible to let the return type of an instantiation of
`std::function` to be itself: `std::function<std::function<std::function<
/* infinite recursion */ >()>()>`. And we found it a common requirement in
polymorphic programming.

Here is an use case in our production: there are many different periodic
tasks in our system, some execute only once, most of them execute several
times with different and variable intervals (e.g., a constant interval *
(100% +/- 10%) to avoid high QPS in a short period of time).  Therefore, it
is required to design a runtime abstraction for periodic task type to
submit to one generic "timed thread pool" that manages several threads. In
order to avoid unnecessary "submission" that may introduce overhead in
contention (e.g., acquire & release some mutex), we think it could be
efficient to let the execution of the abstraction output a type of itself,
e.g.:

std::function<std::optional<std::pair<std::chrono::time_point<std::chrono::system_clock>,
std::function< /* infinite recursion */ >>>()>

.... but we are not able to define that type within finite characters, and
it turned out that we cannot use `std::function` in this case.

*The Solution*

We propose a magic type `std::self`, which does not necessarily be a
complete type. The type above could be written as:

std::function<std::optional<std::pair<std::chrono::time_point<std::chrono::system_clock>,
std::self>>()>

During code generation, `std::self` shall be replaced by the whole name of
the type. For example, the signature of
`std::function<R(Args...)>::operator()` is

R operator()(Args...);

.... when
R=`std::optional<std::pair<std::chrono::time_point<std::chrono::system_clock>,
std::self>>`, Args=<empty>, the signature will be

std::optional<std::pair<std::chrono::time_point<std::chrono::system_clock>,
std::function<std::optional<std::pair<std::chrono::time_point<std::chrono::system_clock>,
std::self>>()>>> operator()();

.... where `std::self` is replaced by
`std::function<std::optional<std::pair<std::chrono::time_point<std::chrono::system_clock>,
std::self>>()>`, and such API works in our use case.

*Application*

We already have an implementation of the "timed thread pool
<https://github.com/wmx16835/wang/blob/master/src/main/experimental/concurrent.h#L235-L385>"
whose runtime abstraction is supported by the PFA (P0957
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0957r1.pdf>), and
we simply hand-wrote the code that should be generated with `std::self`.

I am looking forward to your valuable comments!

Mingxin Wang

--
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/fc5d6b14-cf4c-470c-b377-49a47c0832a9%40isocpp.org.

------=_Part_345_21275312.1538143682718
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><b>The Problem</b></div><div><br></div><div>Currently=
, we are not able to refer to a type in its template. For example, it is im=
possible to let the return type of an instantiation of `std::function` to b=
e itself: `std::function&lt;std::function&lt;std::function&lt; /* infinite =
recursion */ &gt;()&gt;()&gt;`. And we found it a common requirement in pol=
ymorphic programming.</div><div><br></div><div>Here is an use case in our p=
roduction: there are many different periodic tasks in our system, some exec=
ute only once, most of them execute several times with different and variab=
le intervals (e.g., a constant interval * (100% +/- 10%) to avoid high QPS =
in a short period of time).=C2=A0 Therefore, it is required to design a run=
time abstraction for periodic task type to submit to one generic &quot;time=
d thread pool&quot; that manages several threads. In order to avoid unneces=
sary &quot;submission&quot; that may introduce overhead in contention (e.g.=
, acquire &amp; release some mutex), we think it could be efficient to let =
the execution of the abstraction output a type of itself, e.g.:</div><div><=
br></div><div>std::function&lt;std::optional&lt;std::pair&lt;std::chrono::t=
ime_point&lt;std::chrono::system_clock&gt;, std::function&lt; /* infinite r=
ecursion */ &gt;&gt;&gt;()&gt;</div><div><br></div><div>... but we are not =
able to define that type within finite characters, and it turned out that w=
e cannot use `std::function` in this case.</div><div><br></div><div><b>The =
Solution</b></div><div><br></div><div>We propose a magic type `std::self`, =
which does not necessarily be a complete type. The type above could be writ=
ten as:</div><div><br></div><div>std::function&lt;std::optional&lt;std::pai=
r&lt;std::chrono::time_point&lt;std::chrono::system_clock&gt;, std::self&gt=
;&gt;()&gt;</div><div><br></div><div>During code generation, `std::self` sh=
all be replaced by the whole name of the type. For example, the signature o=
f `std::function&lt;R(Args...)&gt;::operator()` is</div><div><br></div><div=
>R operator()(Args...);</div><div><br></div><div>... when R=3D`std::optiona=
l&lt;std::pair&lt;std::chrono::time_point&lt;std::chrono::system_clock&gt;,=
 std::self&gt;&gt;`, Args=3D&lt;empty&gt;, the signature will be</div><div>=
<br></div><div>std::optional&lt;std::pair&lt;std::chrono::time_point&lt;std=
::chrono::system_clock&gt;, std::function&lt;std::optional&lt;std::pair&lt;=
std::chrono::time_point&lt;std::chrono::system_clock&gt;, std::self&gt;&gt;=
()&gt;&gt;&gt; operator()();</div><div><br></div><div>... where `std::self`=
 is replaced by `std::function&lt;std::optional&lt;std::pair&lt;std::chrono=
::time_point&lt;std::chrono::system_clock&gt;, std::self&gt;&gt;()&gt;`, an=
d such API works in our use case.</div><div><br></div><div><b>Application</=
b></div><div><br></div><div>We already have an implementation of the &quot;=
<a href=3D"https://github.com/wmx16835/wang/blob/master/src/main/experiment=
al/concurrent.h#L235-L385">timed thread pool</a>&quot; whose runtime abstra=
ction is supported by the PFA (<a href=3D"http://www.open-std.org/jtc1/sc22=
/wg21/docs/papers/2018/p0957r1.pdf">P0957</a>), and we simply hand-wrote th=
e code that should be generated with `std::self`.</div><div><br></div><div>=
I am looking forward to your valuable comments!</div><div><br></div><div>Mi=
ngxin Wang</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fc5d6b14-cf4c-470c-b377-49a47c0832a9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fc5d6b14-cf4c-470c-b377-49a47c0832a9=
%40isocpp.org</a>.<br />

------=_Part_345_21275312.1538143682718--

------=_Part_344_2112699798.1538143682717--

.

On 9/28/18 5:08 PM, Mingxin Wang wrote:
> *The Problem*
>
> Currently, we are not able to refer to a type in its template. For
> example, it is impossible to let the return type of an instantiation of
> `std::function` to be itself:
> `std::function<std::function<std::function< /* infinite recursion */
>  >()>()>`. And we found it a common requirement in polymorphic programming.

The compiler has to generate a concrete type for template instantiation,
and this is not possible if it includes an infinite recursion. Your
proposed std::self offers a way to describe the type in the code but not
how it could be implemented in the compiler.

--
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/440320b6-c3a4-54e7-6422-d85643bb3b48%40gmail.com.

.

------=_Part_391_1378109295.1538146174050
Content-Type: multipart/alternative;
 boundary="----=_Part_392_1816008023.1538146174050"

------=_Part_392_1816008023.1538146174050
Content-Type: text/plain; charset="UTF-8"

On Friday, September 28, 2018 at 10:21:48 PM UTC+8, Andrey Semashev wrote:
>
> The compiler has to generate a concrete type for template instantiation,
> and this is not possible if it includes an infinite recursion. Your
> proposed std::self offers a way to describe the type in the code but not
> how it could be implemented in the compiler.
>

As far as I am concerned, we only need to add a pre-processing step for the
template parameters, replacing all `std::self` into the declaration (e.g.,
`T<U<std::self>>`, change the first parameter into `U<T<U<std::self>>>`)
before instantiating a type template.

--
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/4809ba9f-b14a-47ea-8a89-b801e3944c44%40isocpp.org.

------=_Part_392_1816008023.1538146174050
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, September 28, 2018 at 10:21:48 PM UTC+8, Andrey=
 Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The compiler h=
as to generate a concrete type for template instantiation,=20
<br>and this is not possible if it includes an infinite recursion. Your=20
<br>proposed std::self offers a way to describe the type in the code but no=
t=20
<br>how it could be implemented in the compiler.
<br></blockquote><div><br></div><div>As far as I am concerned, we only need=
 to add a pre-processing step for the template parameters, replacing all `s=
td::self` into the declaration (e.g., `T&lt;U&lt;std::self&gt;&gt;`, change=
 the first parameter into `U&lt;T&lt;U&lt;std::self&gt;&gt;&gt;`) before in=
stantiating a type template.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4809ba9f-b14a-47ea-8a89-b801e3944c44%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4809ba9f-b14a-47ea-8a89-b801e3944c44=
%40isocpp.org</a>.<br />

------=_Part_392_1816008023.1538146174050--

------=_Part_391_1378109295.1538146174050--

.

------=_Part_391_1452007548.1538147815912
Content-Type: multipart/alternative;
 boundary="----=_Part_392_874442860.1538147815912"

------=_Part_392_874442860.1538147815912
Content-Type: text/plain; charset="UTF-8"

On Friday, September 28, 2018 at 10:21:48 PM UTC+8, Andrey Semashev wrote:
>
> The compiler has to generate a concrete type for template instantiation,
> and this is not possible if it includes an infinite recursion. Your
> proposed std::self offers a way to describe the type in the code but not
> how it could be implemented in the compiler.
>

Thank you for the comment.

You are right, and I realized that the semantics of the proposed
`std::self` is broken, because it only start recursing from the outermost
layer of the template, and thus could not represent a type template
specified by a "recursive type" without an alias. For example,
`T<std::self>` could not be a template parameter of another type template
`U`, because `U<T<std::self>>` means `U<T<U<T<...>>>>` rather than
`U<T<T<T<...>>>>`.

However, since this problem exists objectively, I think we still need to
find another way to solve it.

--
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/26075890-ba85-4cb3-a9da-ecae3788b226%40isocpp.org.

------=_Part_392_874442860.1538147815912
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, September 28, 2018 at 10:21:48 PM UTC+8, Andrey=
 Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The compiler h=
as to generate a concrete type for template instantiation,=20
<br>and this is not possible if it includes an infinite recursion. Your=20
<br>proposed std::self offers a way to describe the type in the code but no=
t=20
<br>how it could be implemented in the compiler.
<br></blockquote><div><br></div><div>Thank you for the comment.</div><div><=
br></div><div>You are right, and I realized that the semantics of the propo=
sed `std::self` is broken, because it only start recursing from the outermo=
st layer of the template, and thus could not represent a type template spec=
ified by a &quot;recursive type&quot; without an alias. For example, `T&lt;=
std::self&gt;` could not be a template parameter of another type template `=
U`, because `U&lt;T&lt;std::self&gt;&gt;` means `U&lt;T&lt;U&lt;T&lt;...&gt=
;&gt;&gt;&gt;` rather than `U&lt;T&lt;T&lt;T&lt;...&gt;&gt;&gt;&gt;`.</div>=
<div><br></div><div>However, since this problem exists objectively, I think=
 we still need to find another way to solve it.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/26075890-ba85-4cb3-a9da-ecae3788b226%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/26075890-ba85-4cb3-a9da-ecae3788b226=
%40isocpp.org</a>.<br />

------=_Part_392_874442860.1538147815912--

------=_Part_391_1452007548.1538147815912--

.

------=_Part_630_2028444620.1538190976244
Content-Type: multipart/alternative;
 boundary="----=_Part_631_1776511240.1538190976244"

------=_Part_631_1776511240.1538190976244
Content-Type: text/plain; charset="UTF-8"

I have got a new idea to solve this problem: allow using a type template as
a type parameter that has "recursive" semantics in template instantiation.

Besides adding a magic class `std::self` as a generic placeholder, it seems
syntactically reasonable just to use the name of the type template, staying
consistent with the way we refer to a type inside its implementation. For
example, if we have:

template <class T> class A;
template <class T> class B;

.... `A<B<A>>` indicates `A<B<A<B<...>>>>`, and `A<B<B>>` indicates
`A<B<B<B<...>>>>`.

What do you think of this idea?

--
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/8794ff0f-5f42-4f11-8231-23691ed87ae3%40isocpp.org.

------=_Part_631_1776511240.1538190976244
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I have got a new idea to solve this problem: allow us=
ing a type template as a type parameter that has &quot;recursive&quot; sema=
ntics in template instantiation.</div><div><br></div><div>Besides adding a =
magic class `std::self` as a generic placeholder, it seems syntactically re=
asonable just to use the name of the type template, staying consistent with=
 the way we refer to a type inside its implementation. For example, if we h=
ave:</div><div><br></div><div>template &lt;class T&gt; class A;</div><div>t=
emplate &lt;class T&gt; class B;</div><div><br></div><div>... `A&lt;B&lt;A&=
gt;&gt;` indicates `A&lt;B&lt;A&lt;B&lt;...&gt;&gt;&gt;&gt;`, and `A&lt;B&l=
t;B&gt;&gt;` indicates `A&lt;B&lt;B&lt;B&lt;...&gt;&gt;&gt;&gt;`.</div><div=
><br></div><div>What do you think of this idea?</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8794ff0f-5f42-4f11-8231-23691ed87ae3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8794ff0f-5f42-4f11-8231-23691ed87ae3=
%40isocpp.org</a>.<br />

------=_Part_631_1776511240.1538190976244--

------=_Part_630_2028444620.1538190976244--

.

------=_Part_212_1318803359.1538289091013
Content-Type: multipart/alternative;
 boundary="----=_Part_213_65635418.1538289091013"

------=_Part_213_65635418.1538289091013
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

As mentioned, the required semantics can not be implemented. There are=20
multiple issues.

Infinitely recursive types are ill-typed in any type system with mandatory=
=20
static typechecking which requires strong normalization property on=20
typechecking algorithm (i.e. they shall eventually terminate). The=20
typechecking of well-typedness of a parameteric type depends on its=20
parameter types, so naively infinite types are not allowed.

The case recalls me that undelimited continuations are not functions=20
<http://okmij.org/ftp/continuations/undelimited.html#introduction> when=20
there is no native =E2=8A=A5(falsum) type to be allowed in the language. Si=
milar=20
by-definition logic inconsistency is the essential reason why all trivial=
=20
(as simple as to add a new form of types) workarounds seem incomplete and=
=20
problematic, besides *typechecking *(but *typing*): you have genuine=20
"static" typing only when you have a deterministic process to give specific=
=20
terms with proper types before certain predefined remained computation in=
=20
the program. Thus you have at least two kinds of problems: a) Which terms=
=20
qualify the target of newly added types? b) What is the boundary of=20
"static"? The second problem is particular annoying because adapting the=20
workaround to the current type system would be, errrr..., a problem=20
factory. For example, with your first proposed mechanism, there comes a=20
serious chicken-egg contradiction: how to determine "whole name of the=20
type"? With your second proposed one, the problem will be "when to expand=
=20
the type name to its instance" or even "how to determine the equivalence=20
among types". All of such modifications of type system need non-trivial=20
rules to make it still consistent with "static" typing.

In C++ static typing occurs before translation phase 7 (which is the common=
=20
case). Without later resolution, the limitation would be still effective=20
even you have changed the rules (both well-typing and phases) and made the=
=20
compiler behave as an interpreter with AOT-interpreted output (i.e. a=20
partial evaluator). So anyway, you have to erase the static types if you=20
want to recurse on these types as parameters. The resulted erased wrapper=
=20
is then the lazily evaluated thunk of continuation which would be resolved=
=20
later.

--=20
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 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/0a5a8ed3-c0bf-47b5-8842-b6733997dc40%40isocpp.or=
g.

------=_Part_213_65635418.1538289091013
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">As mentioned, the required semantics can not be implemente=
d. There are multiple issues.<br><br>Infinitely recursive types are ill-typ=
ed in any type system with mandatory static typechecking which requires str=
ong normalization property on typechecking algorithm (i.e. they shall event=
ually terminate). The typechecking of well-typedness of a parameteric type =
depends on its parameter types, so naively infinite types are not allowed.<=
br><br>The case recalls me that <a href=3D"http://okmij.org/ftp/continuatio=
ns/undelimited.html#introduction">undelimited continuations are not functio=
ns</a> when there is no native =E2=8A=A5(falsum) type to be allowed in the =
language. Similar by-definition logic inconsistency is the essential reason=
 why all trivial (as simple as to add a new form of types) workarounds seem=
 incomplete and problematic, besides <i>typechecking </i>(but <i>typing</i>=
): you have genuine &quot;static&quot; typing only when you have a determin=
istic process to give specific terms with proper types before certain prede=
fined remained computation in the program. Thus you have at least two kinds=
 of problems: a) Which terms qualify the target of newly added types? b) Wh=
at is the boundary of &quot;static&quot;? The second problem is particular =
annoying because adapting the workaround to the current type system would b=
e, errrr..., a problem factory. For example, with your first proposed mecha=
nism, there comes a serious chicken-egg contradiction: how to determine &qu=
ot;whole name of the type&quot;? With your second proposed one, the problem=
 will be &quot;when to expand the type name to its instance&quot; or even &=
quot;how to determine the equivalence among types&quot;. All of such modifi=
cations of type system need non-trivial rules to make it still consistent w=
ith &quot;static&quot; typing.<br><br>In C++ static typing occurs before tr=
anslation phase 7 (which is the common case). Without later resolution, the=
 limitation would be still effective even you have changed the rules (both =
well-typing and phases) and made the compiler behave as an interpreter with=
 AOT-interpreted output (i.e. a partial evaluator). So anyway, you have to =
erase the static types if you want to recurse on these types
 as parameters. The resulted erased wrapper is then the lazily evaluated
 thunk of continuation which would be resolved later.<br><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0a5a8ed3-c0bf-47b5-8842-b6733997dc40%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0a5a8ed3-c0bf-47b5-8842-b6733997dc40=
%40isocpp.org</a>.<br />

------=_Part_213_65635418.1538289091013--

------=_Part_212_1318803359.1538289091013--

.

------=_Part_950_862551162.1538365993103
Content-Type: multipart/alternative;
 boundary="----=_Part_951_1702531945.1538365993103"

------=_Part_951_1702531945.1538365993103
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sunday, September 30, 2018 at 2:31:31 PM UTC+8, FrankHB1989 wrote:
>
> As mentioned, the required semantics can not be implemented. There are=20
> multiple issues.
>
> Infinitely recursive types are ill-typed in any type system with mandator=
y=20
> static typechecking which requires strong normalization property on=20
> typechecking algorithm (i.e. they shall eventually terminate). The=20
> typechecking of well-typedness of a parameteric type depends on its=20
> parameter types, so naively infinite types are not allowed.
>

In the second proposed mechanism, the name of the template is regarded as a=
=20
placeholder typename with contextual recursive semantics, and thus the=20
instantiated template is still finite.=20

The case recalls me that undelimited continuations are not functions=20
> <http://okmij.org/ftp/continuations/undelimited.html#introduction> when=
=20
> there is no native =E2=8A=A5(falsum) type to be allowed in the language. =
Similar=20
> by-definition logic inconsistency is the essential reason why all trivial=
=20
> (as simple as to add a new form of types) workarounds seem incomplete and=
=20
> problematic, besides *typechecking *(but *typing*): you have genuine=20
> "static" typing only when you have a deterministic process to give specif=
ic=20
> terms with proper types before certain predefined remained computation in=
=20
> the program.
>

A type template instantiation with recursive semantics is still a static=20
type.
=20

> Thus you have at least two kinds of problems: a) Which terms qualify the=
=20
> target of newly added types? b) What is the boundary of "static"? The=20
> second problem is particular annoying because adapting the workaround to=
=20
> the current type system would be, errrr..., a problem factory.
>

a) Compiler could treat each type template name as a placeholder type.
b) This feature may require contextually parsing, but it only happens at=20
compile-time.
=20

> For example, with your first proposed mechanism, there comes a serious=20
> chicken-egg contradiction: how to determine "whole name of the type"?
>

That is true. The semantics of the first mechanism in my initial post is=20
broken.
=20

> With your second proposed one, the problem will be "when to expand the=20
> type name to its instance"
>

As far as I am concerned, there should be two prerequirements:
1. The template parameter shall be a typename (class), other than a=20
typename template or an integral constant.
For example, `A<B<A>>` to be well-formed requires the first template=20
parameter of `B` is a typename, or it is ill-formed, e.g the definition  of=
=20
`B` is `template <bool B> class B`.
2. The recursive template name shall appear in its upper-level template.
For example, while `A<B<A>>` is well-formed, `A<B<C>>` is not, providing=20
`C` is a type template.
=20

> or even "how to determine the equivalence among types".
>

The method to "determine the equivalence among types" could remain=20
unchanged. For example, `A<B<A>>` and `A<B<A<B<A>>>>` are not the same=20
type, even if they generate similar code. However, the use of=20
`A<B<A<B<A>>>>` could usually be reconstructed with `A<B<A>>`, and thus=20
compilers may warn for such usage.

--=20
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 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/2dffdeff-1912-41bf-8eaf-1391b1a28c4c%40isocpp.or=
g.

------=_Part_951_1702531945.1538365993103
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, September 30, 2018 at 2:31:31 PM UTC+8, FrankHB=
1989 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">As=
 mentioned, the required semantics can not be implemented. There are multip=
le issues.<br><br>Infinitely recursive types are ill-typed in any type syst=
em with mandatory static typechecking which requires strong normalization p=
roperty on typechecking algorithm (i.e. they shall eventually terminate). T=
he typechecking of well-typedness of a parameteric type depends on its para=
meter types, so naively infinite types are not allowed.<br></div></blockquo=
te><div><br></div><div>In the second proposed mechanism, the name of the te=
mplate is regarded as a placeholder typename with contextual recursive sema=
ntics, and thus the instantiated template is still finite.=C2=A0</div><div>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">The=
 case recalls me that <a href=3D"http://okmij.org/ftp/continuations/undelim=
ited.html#introduction" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fokmij.org%2Fftp=
%2Fcontinuations%2Fundelimited.html%23introduction\x26sa\x3dD\x26sntz\x3d1\=
x26usg\x3dAFQjCNGwxdr6ldsATWm4AEicl6ZUkzSeuQ&#39;;return true;" onclick=3D"=
this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fokmij.org%2Fft=
p%2Fcontinuations%2Fundelimited.html%23introduction\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNGwxdr6ldsATWm4AEicl6ZUkzSeuQ&#39;;return true;">undelimite=
d continuations are not functions</a> when there is no native =E2=8A=A5(fal=
sum) type to be allowed in the language. Similar by-definition logic incons=
istency is the essential reason why all trivial (as simple as to add a new =
form of types) workarounds seem incomplete and problematic, besides <i>type=
checking </i>(but <i>typing</i>): you have genuine &quot;static&quot; typin=
g only when you have a deterministic process to give specific terms with pr=
oper types before certain predefined remained computation in the program.</=
div></blockquote><div><br></div><div>A type template instantiation with rec=
ursive semantics is still a static type.</div><div>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Thus you have at least tw=
o kinds of problems: a) Which terms qualify the target of newly added types=
? b) What is the boundary of &quot;static&quot;? The second problem is part=
icular annoying because adapting the workaround to the current type system =
would be, errrr..., a problem factory.</div></blockquote><div><br></div><di=
v>a) Compiler could treat each type template name as a placeholder type.</d=
iv><div>b) This feature may require contextually=C2=A0parsing, but it only =
happens at compile-time.</div><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr">For example, with your first proposed mec=
hanism, there comes a serious chicken-egg contradiction: how to determine &=
quot;whole name of the type&quot;?</div></blockquote><div><br></div><div>Th=
at is true. The semantics of the first mechanism in my initial post is brok=
en.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
 dir=3D"ltr">With your second proposed one, the problem will be &quot;when =
to expand the type name to its instance&quot;</div></blockquote><div><br></=
div><div>As far as I am concerned, there should be two prerequirements:</di=
v><div>1. The template parameter shall be a typename (class), other than a =
typename template or an integral constant.</div><div>For example, `A&lt;B&l=
t;A&gt;&gt;` to be well-formed requires the first template parameter of `B`=
 is a typename, or it is ill-formed, e.g the definition=C2=A0 of `B` is `te=
mplate &lt;bool B&gt; class B`.</div><div>2. The recursive template name sh=
all appear in its upper-level template.</div><div>For example, while `A&lt;=
B&lt;A&gt;&gt;` is well-formed, `A&lt;B&lt;C&gt;&gt;` is not, providing `C`=
 is a type template.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;"><div dir=3D"ltr">or even &quot;how to determine the equivalenc=
e among types&quot;.</div></blockquote><div><br></div><div>The method to &q=
uot;determine the equivalence among types&quot; could remain unchanged. For=
 example, `A&lt;B&lt;A&gt;&gt;` and `A&lt;B&lt;A&lt;B&lt;A&gt;&gt;&gt;&gt;`=
 are not the same type, even if they generate similar code. However, the us=
e of `A&lt;B&lt;A&lt;B&lt;A&gt;&gt;&gt;&gt;` could usually be reconstructed=
 with `A&lt;B&lt;A&gt;&gt;`, and thus compilers may warn for such usage.</d=
iv></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2dffdeff-1912-41bf-8eaf-1391b1a28c4c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2dffdeff-1912-41bf-8eaf-1391b1a28c4c=
%40isocpp.org</a>.<br />

------=_Part_951_1702531945.1538365993103--

------=_Part_950_862551162.1538365993103--

.

------=_Part_599_158502312.1538574232856
Content-Type: multipart/alternative;
 boundary="----=_Part_600_1363599420.1538574232856"

------=_Part_600_1363599420.1538574232856
Content-Type: text/plain; charset="UTF-8"

On Sunday, September 30, 2018 at 7:31:31 AM UTC+1, FrankHB1989 wrote:
>
> As mentioned, the required semantics can not be implemented. There are
> multiple issues.
>
> Infinitely recursive types are ill-typed in any type system with mandatory
> static typechecking which requires strong normalization property on
> typechecking algorithm (i.e. they shall eventually terminate). The
> typechecking of well-typedness of a parameteric type depends on its
> parameter types, so naively infinite types are not allowed.
>

I have no opinion on the proposal itself, but I think that C++ already
fails this property. Because templates can be recursive today, short of
hitting internal compiler limits, type checking is not guaranteed to
terminate. You can already instantiate recursive types today in C++ by
introducing a strong typedef:

template<class> class A;

struct A_rec;
using A_rec_ = A<A_rec>;
struct A_rec : A_rec_ {};

-- gpd

--
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/6837eea5-60c5-4db8-91c8-9d425a777eb8%40isocpp.org.

------=_Part_600_1363599420.1538574232856
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, September 30, 2018 at 7:31:31 AM UTC+1, FrankHB=
1989 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">As=
 mentioned, the required semantics can not be implemented. There are multip=
le issues.<br><br>Infinitely recursive types are ill-typed in any type syst=
em with mandatory static typechecking which requires strong normalization p=
roperty on typechecking algorithm (i.e. they shall eventually terminate). T=
he typechecking of well-typedness of a parameteric type depends on its para=
meter types, so naively infinite types are not allowed.<br></div></blockquo=
te><div dir=3D"ltr"><br>I have no opinion on the proposal itself, but I thi=
nk that C++ already fails this property. Because templates can be recursive=
 today, short of hitting internal compiler limits, type checking is not gua=
ranteed to terminate. You can already instantiate recursive types today in =
C++ by introducing a strong typedef:<br><br>template&lt;class&gt; class A;<=
br><br>struct A_rec;<br>using A_rec_ =3D A&lt;A_rec&gt;;<br>struct A_rec : =
A_rec_ {};<br><br>-- gpd<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6837eea5-60c5-4db8-91c8-9d425a777eb8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6837eea5-60c5-4db8-91c8-9d425a777eb8=
%40isocpp.org</a>.<br />

------=_Part_600_1363599420.1538574232856--

------=_Part_599_158502312.1538574232856--

.

On 10/3/18 4:43 PM, Giovanni Piero Deretta wrote:
> On Sunday, September 30, 2018 at 7:31:31 AM UTC+1, FrankHB1989 wrote:
>
>     As mentioned, the required semantics can not be implemented. There
>     are multiple issues.
>
>     Infinitely recursive types are ill-typed in any type system with
>     mandatory static typechecking which requires strong normalization
>     property on typechecking algorithm (i.e. they shall eventually
>     terminate). The typechecking of well-typedness of a parameteric type
>     depends on its parameter types, so naively infinite types are not
>     allowed.
>
> I have no opinion on the proposal itself, but I think that C++ already
> fails this property. Because templates can be recursive today, short of
> hitting internal compiler limits, type checking is not guaranteed to
> terminate. You can already instantiate recursive types today in C++ by
> introducing a strong typedef:

Recursive template instantiations are possible and were used for a long
time (e.g. in C++03 type lists), but they are never infinitely recursive.

> template<class> class A;
>
> struct A_rec;
> using A_rec_ = A<A_rec>;
> struct A_rec : A_rec_ {};

This won't work because A is not defined at the point of A_rec definition.

If you define A this way:

   template<class T> class A : T {};

or any other way that requires T to be fully defined then it still won't
work because then, obviously, A_rec is not defined at the point of its
definition.

--
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/805af406-c1f5-ac55-4550-bd5725d6a7b2%40gmail.com.

.

------=_Part_2414_923888071.1538576423594
Content-Type: multipart/alternative;
 boundary="----=_Part_2415_363742491.1538576423594"

------=_Part_2415_363742491.1538576423594
Content-Type: text/plain; charset="UTF-8"

On Wednesday, October 3, 2018 at 2:58:42 PM UTC+1, Andrey Semashev wrote:
>
> On 10/3/18 4:43 PM, Giovanni Piero Deretta wrote:
> > On Sunday, September 30, 2018 at 7:31:31 AM UTC+1, FrankHB1989 wrote:
> >
> >     As mentioned, the required semantics can not be implemented. There
> >     are multiple issues.
> >
> >     Infinitely recursive types are ill-typed in any type system with
> >     mandatory static typechecking which requires strong normalization
> >     property on typechecking algorithm (i.e. they shall eventually
> >     terminate). The typechecking of well-typedness of a parameteric type
> >     depends on its parameter types, so naively infinite types are not
> >     allowed.
> >
> > I have no opinion on the proposal itself, but I think that C++ already
> > fails this property. Because templates can be recursive today, short of
> > hitting internal compiler limits, type checking is not guaranteed to
> > terminate. You can already instantiate recursive types today in C++ by
> > introducing a strong typedef:
>
> Recursive template instantiations are possible and were used for a long
> time (e.g. in C++03 type lists), but they are never infinitely recursive.
>


template<int i>
struct x { enum { value = x<i+1>::value }; };


// template<>
// struct x<100> { enum {value = 100}; };

enum {foo = x<0>::value };

This will fail with an en error for having hit the implementation defined
recursion limit. The error can be quenched by uncommenting the stop
condition.

The template itself is infinitely recursive. On a theoretical compiler
build on a actual turing machine, it need not ever terminate.


> > template<class> class A;
> >
> > struct A_rec;
> > using A_rec_ = A<A_rec>;
> > struct A_rec : A_rec_ {};
>
> This won't work because A is not defined at the point of A_rec definition.
>
> If you define A this way:
>
>    template<class T> class A : T {};
>
> or any other way that requires T to be fully defined then it still won't
> work because then, obviously, A_rec is not defined at the point of its
> definition.
>

yes, of course T cannot be fully defined at the point of instantiation of A
but that's not a requirement. For example you do not need it to implement
recursive variants.


--
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/bad00f70-5fe4-4249-a400-4d74a41646de%40isocpp.org.

------=_Part_2415_363742491.1538576423594
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, October 3, 2018 at 2:58:42 PM UTC+1, Andrey =
Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 10/3/18 4:43=
 PM, Giovanni Piero Deretta wrote:
<br>&gt; On Sunday, September 30, 2018 at 7:31:31 AM UTC+1, FrankHB1989 wro=
te:
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 As mentioned, the required semantics can not be impl=
emented. There
<br>&gt; =C2=A0 =C2=A0 are multiple issues.
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 Infinitely recursive types are ill-typed in any type=
 system with
<br>&gt; =C2=A0 =C2=A0 mandatory static typechecking which requires strong =
normalization
<br>&gt; =C2=A0 =C2=A0 property on typechecking algorithm (i.e. they shall =
eventually
<br>&gt; =C2=A0 =C2=A0 terminate). The typechecking of well-typedness of a =
parameteric type
<br>&gt; =C2=A0 =C2=A0 depends on its parameter types, so naively infinite =
types are not
<br>&gt; =C2=A0 =C2=A0 allowed.
<br>&gt;=20
<br>&gt; I have no opinion on the proposal itself, but I think that C++ alr=
eady=20
<br>&gt; fails this property. Because templates can be recursive today, sho=
rt of=20
<br>&gt; hitting internal compiler limits, type checking is not guaranteed =
to=20
<br>&gt; terminate. You can already instantiate recursive types today in C+=
+ by=20
<br>&gt; introducing a strong typedef:
<br>
<br>Recursive template instantiations are possible and were used for a long=
=20
<br>time (e.g. in C++03 type lists), but they are never infinitely recursiv=
e.
<br></blockquote><div><br><br>template&lt;int i&gt;<br>struct x { enum { va=
lue =3D x&lt;i+1&gt;::value }; };<br><br><br>// template&lt;&gt;<br>// stru=
ct x&lt;100&gt; { enum {value =3D 100}; };<br><br>enum {foo =3D x&lt;0&gt;:=
:value };<br><br></div><div>This will fail with an en error for having hit =
the implementation defined recursion limit. The error can be quenched by un=
commenting the stop condition. <br><br>The template itself is infinitely re=
cursive. On a theoretical compiler build on a actual turing machine, it nee=
d not ever terminate.<br>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;">&gt; template&lt;class&gt; class A;
<br>&gt;=20
<br>&gt; struct A_rec;
<br>&gt; using A_rec_ =3D A&lt;A_rec&gt;;
<br>&gt; struct A_rec : A_rec_ {};
<br>
<br>This won&#39;t work because A is not defined at the point of A_rec defi=
nition.
<br>
<br>If you define A this way:
<br>
<br>=C2=A0 =C2=A0template&lt;class T&gt; class A : T {};
<br>
<br>or any other way that requires T to be fully defined then it still won&=
#39;t=20
<br>work because then, obviously, A_rec is not defined at the point of its=
=20
<br>definition.
<br></blockquote><div><br>yes, of course T cannot be fully defined at the p=
oint of instantiation of A but that&#39;s not a requirement. For example yo=
u do not need it to implement recursive variants.<br>=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bad00f70-5fe4-4249-a400-4d74a41646de%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bad00f70-5fe4-4249-a400-4d74a41646de=
%40isocpp.org</a>.<br />

------=_Part_2415_363742491.1538576423594--

------=_Part_2414_923888071.1538576423594--

.

On 10/3/18 5:20 PM, Giovanni Piero Deretta wrote:
> On Wednesday, October 3, 2018 at 2:58:42 PM UTC+1, Andrey Semashev wrote:
>
>     Recursive template instantiations are possible and were used for a long
>     time (e.g. in C++03 type lists), but they are never infinitely
>     recursive.
>
> template<int i>
> struct x { enum { value = x<i+1>::value }; };
>
>
> // template<>
> // struct x<100> { enum {value = 100}; };
>
> enum {foo = x<0>::value };
>
> This will fail with an en error for having hit the implementation
> defined recursion limit. The error can be quenched by uncommenting the
> stop condition.
>
> The template itself is infinitely recursive. On a theoretical compiler
> build on a actual turing machine, it need not ever terminate.

There cannot be an actual Turing machine because there cannot be an
infinite memory tape. Similarly, no actual compiler can implement
infinite template recursion because it operates within a limited amount
of memory.

In your example the template causes infinite recursion, which is exactly
the reason why it fails to compile. C++ recognizes this fundamental
limitation, so in [temp.inst]/16 it says there is a limit of recursive
instantiations depth and that the result of infinite recursion is
undefined. Which makes the program not a legal C++.

--
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/8625de87-60b3-15af-9740-05b0be8e8ccf%40gmail.com.

.