Topic: Defining "immediate context
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 8 Apr 2016 06:31:53 -0700 (PDT)
Raw View
------=_Part_573_1961686176.1460122313363
Content-Type: multipart/alternative;
boundary="----=_Part_574_205601501.1460122313363"
------=_Part_574_205601501.1460122313363
Content-Type: text/plain; charset=UTF-8
Hi,
I would like to ask if anyone is working on the definition of "immediate
context". I have done some investigation on my own, and wanted to share the
results here
<https://htmlpreview.github.io/?https://github.com/akrzemi1/__sandbox__/blob/master/immediate_context.html>.
I wanted to check if this is not overlapping with somebody else's work.
Regards,
&rzej
--
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/93414c19-68a5-4970-b077-75e7eefb7d02%40isocpp.org.
------=_Part_574_205601501.1460122313363
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<br>I would like to ask if anyone is working on the def=
inition of "immediate context". I have done some investigation on=
my own, and wanted to share the results <a href=3D"https://htmlpreview.git=
hub.io/?https://github.com/akrzemi1/__sandbox__/blob/master/immediate_conte=
xt.html">here</a>. I wanted to check if this is not overlapping with somebo=
dy else's work.<br><br>Regards,<br>&rzej<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/93414c19-68a5-4970-b077-75e7eefb7d02%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/93414c19-68a5-4970-b077-75e7eefb7d02=
%40isocpp.org</a>.<br />
------=_Part_574_205601501.1460122313363--
------=_Part_573_1961686176.1460122313363
Content-Type: text/html; charset=windows-1252; name=immediate_context.html
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename=immediate_context.html
X-Attachment-Id: 88d4f6ba-7dcd-4952-a550-dd05c25caeb3
Content-ID: <88d4f6ba-7dcd-4952-a550-dd05c25caeb3>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/htm=
l4/strict.dtd">
<html><head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<title>Deleted functions in template argument substitution</title>
<style type=3D"text/css">
p {text-align:justify}
ins {background-color:#A0FFA0}
ins > ul > li {
background-color:#A0FFA0;
list-style-type: none;
margin-left: -0.5em;
padding-left: 0.5em;
}
ins > ul > li:before {
display: inline-block;=20
content: "=97";
width: 1em;
margin-left: -0.5em;
margin-right: 0.5em;
}
ul > li {
list-style-type: none;
margin-left: -0.5em;
padding-left: 0.5em;
}
ul > li:before {
display: inline-block;=20
content: "=97";
width: 1em;
margin-left: -0.5em;
margin-right: 0.5em;
}
del {background-color:#FFA0A0}
blockquote.note
{
background-color:#E0E0E0;
padding-left: 15px;
padding-right: 15px;
padding-top: 1px;
padding-bottom: 1px;
}
</style>
</head><body>
<address style=3D"text-align: left;">
Document number: XXXXXX<br/>
Date: YYYY-MM-DD<br/>
Project: Programming Language C++<br/>
Audience: Core Language Working Group<br/>
Reply-to: <a href=3D"mailto:akrzemi1@gmail.com">Andrzej Krzemienski</a>
</address>
<hr>
<h1 style=3D"text-align: center;">Deleted functions in template argument su=
bstitution</h1>
This paper proposes no changes to the language (or the Standard Library). I=
t only offers a wording that clarifies a couple of things:
<ol>
<li>How deleted functions are treated in SFINAE contexts.</li>
<li>What constitutes the "immediate context" during stemplate argument subs=
titution.</li>
<li>When can a template be instantiated during the substitution.</li>
</ol>
Additionally, it provides a brief and formal term "superficially well-forme=
d" as a replacement for long
repetitive and non-normative explanations in Clause 20.13, like=20
<blockquote>"Access checking
is performed as if in a
context unrelated to <code>T</code> and
<code>U</code>. Only the validity of the
immediate context of the
assignment expression is
considered. [<i>Note:</i> The
compilation of the
expression can result in
side effects such as the
instantiation of class
template specializations
and function template
specializations, the
generation of
implicitly-defined
functions, and so on. Such
side effects are not in the
“immediate context” and
can result in the program
being ill-formed. <i>— end
note</i>]" </blockquote>
<h2>Remaining issues</h2>
<p>Currently the definition of <em>superficially well-formed expression</em=
> is located in 20.13 [meta] (library section).
It should be moved to the language section, soe that SFINAE based on expres=
sions can also make use of it.
Perhaps it should be located in section clause Expressions.</p>
<p>Perhaps we need to define a subset of ill-formed conditions as "type-sys=
tem failues" and say that only type-system
failues in overload resolution and superficial well-formedness get turned i=
nto compile-time predicates.=20
It is confusing to see "if X happens program is ill-formed; if program is i=
ll-formed, it is fine and we return <code>true</code> and it is back well f=
ormed.</p>
<h2>Proposed wording</h2>
<p>(Relative to N4582.)</p>
<ol>
<!--
<li>In 14.8.2 [temp.deduct] change paragraph 8 as indicated:
<blockquote>
<ins>A type or an expression <code>E</code> is said to be in a <em>remote c=
ontext</em> of the function type and its template parameter types, when:
<ul>
<li>a class template specialization is instantiated in the process of subst=
itution, and <code>E</code> is a member thereof, or</li>
<li>a function template specialization is instantiated in the process of su=
bstitution, and <code>E</code> occurs in its definition, or</li>
<li>an implicitly-defined non-deleted function is generated in the process =
of substitution, and <code>E</code> occurs in its definition.</li>
</ul>
</ins>
<del>If a substitution results in an invalid type or expression, type deduc=
tion fails.</del> An invalid type or expression is
one that would be ill-formed, with a diagnostic required, if written using =
the substituted arguments. [<i>Note</i>:
If no diagnostic is required, the program is still ill-formed. <del>Access =
checking is done as part of the substitution
process.</del> — <i>end note</i>] <del>Only invalid types and express=
ions in the immediate context of the function type and
its template parameter types can result in a deduction failure. [<i>Note</i=
>: The evaluation of the substituted
types and expressions can result in side effects such as the instantiation =
of class template specializations
and/or function template specializations, the generation of implicitly-defi=
ned functions, etc. Such side effects
are not in the =93immediate context=94 and can result in the program being =
ill-formed. — <i>end note</i>]</del>
<ins>If a substitution results in an invalid type or expression in a remote=
context, the program is ill-formed.=20
If a substitution results in an invalid type or expression in a non-remote =
context, type deduction fails.
Access checking is done as part of the substitution process, in the contex=
t unrelated to the types of sub-expressions of <code>E</code>.</ins>
<br><br />
<ins>An expressions <code>X</code> is said to be <em>superficially well-for=
med</em> when its substitution ends in type deduction success.
[<i>Note</i>: An expression may be determined to be superficially well-for=
med and yet its odr-use may cause a program to be ill-formed. — <i>en=
d note</i>] </ins>
<br />
[<i>Example</i>:<pre>
struct X { };
struct Y {
Y(X){}
};
template <class T> auto f(T t1, T t2) -> decltype(t1 + t2); <i>// #=
1</i>
X f(Y, Y); <i>// #2</i>
X x1, x2;
=20
X x3 =3D f(x1, x2); <i>// deduction fails on #1 (cannot add X+X), calls #=
2</i>
</pre>— <i>end example</i>]
</blockquote>
</li>-->
<li><p>In 8.4.3 [dcl.fct.def.delete] change paragraph 2 as indicated:</p>
<blockquote>A program that refers to a deleted function implicitly or expli=
citly, other than to declare it, is ill-formed.
[<i>Note:</i> This includes calling the function implicitly or explicitly a=
nd forming a pointer or pointer-to-member
to the function. It applies even for references in expressions that are not=
potentially-evaluated. If a function
is overloaded, it is referenced only if the function is selected by overloa=
d resolution. The implicit odr-use (3.2)
of a virtual function does not, by itself, constitute a reference. <i>&mdas=
h;end note</i>]
<ins>[<i>Note:</i> Making a program ill-formed while determining if an expr=
ession is superficially well-formed (20.13) has special meaning and may not=
in fact result in the program being ill-formed. <i>—end note</i>]</i=
ns></blockquote>
</li>
<li><p>Insert somewere at the beginning of 20.13 [meta] the following:</p>
<blockquote>
<p>A number of traits in this clause need to determine if a given expressio=
n <code>E</code> is well-formed for a number of types <code>Tn</code>.</p>
<p>A type or an expression <code>X</code> is said to be in the <em>immediat=
e context</em> of expression <code>E</code> when in the process of determin=
ation of well-formedness of <code>E</code> none of the following is the cas=
e:
<ul>
<li>a class template specialization is instantiated and <code>X</code> is a=
member thereof, or</li>
<li>a function template specialization is instantiated and <code>X</code> o=
ccurs in the definition thereof, or</li>
<li>an implicitly-defined non-deleted function is generated and <code>X</co=
de> occurs in the definition thereof.</li>
</ul>
</p>
<p>The process of determining the well-formedness of a type or expression <=
code>E</code> may instantiate a class template specialization if and only i=
f this specialization must be used to determine the validity of a type or s=
ubexpression of <code>E</code>, in a way that requires the class type to be=
complete (3.2). Similarly, the process of determining the well-formedness =
of a type or expression <code>E</code> may instantiate a function template =
specialization if and only if it needs to deduce the function's return type=
from its definition (7.1.6.4).</p>
<p>A type or an expression <code>X</code> is said to be <em>invalid</em> if=
forming it, during the instantiation of expression <code>E</code> with arg=
uments <code>Tn</code>, would make the program ill-formed, with a diagnosti=
c required. Access checking is performed as if in a context unrelated to an=
y of types <code>Tn</code>.</p>
<p>An expression <code>E</code> is <em>deeply ill-formed</em> for types <co=
de>Tn</code> when instantiaing <code>E</code> with arguments <code>Tn</code=
> would cause any subexpression or type <code>X</code> in the non-immediate=
context of <code>E</code> to be invalid, or if it would resut in exceeding=
one of the implementation-defined limits. An expression <code>E</code> is =
<em>deeply well-formed</em> when it is not deeply ill-formed.</p>
<p>An expression <code>E</code> is <em>superficially ill-formed</em> for ty=
pes <code>Tn</code> when it is deeply well-formed for <code>Tn</code> and w=
hen instantiaing <code>E</code> with arguments <code>Tn</code> would cause =
any subexpression or type <code>X</code> in the immediate context of <code>=
E</code> to be invalid. An expression <code>E</code> is <em>superficially w=
ell-formed</em> for types <code>Tn</code> when it is deeply well-formed for=
<code>Tn</code>, and it is not superficially ill-formed for <code>Tn</code=
>. Determining that an expression is superficially ill-formed does not make=
the program ill-formed. [<i>Note:</i> An expression may be determined to b=
e superficially well-formed and yet its odr-use may cause a program to be i=
ll-formed. </i>— end note</i>]</p>
<p>[<i>Example:</i> Given the following definitions:<pre>
template <class T> struct S {
using type =3D T[2];
};
template <class T, class U =3D void, class V =3D typename S<U>::=
type>
auto f(T) -> V&;
template <class T, class U =3D void, class V =3D U[2]>
auto g(T) -> V&;
template <class T>=20
void h(T) { static_assert(sizeof(T) =3D=3D 0); }
</pre>
Expression <code>f(1)</code> is deeply ill-formed because an invalid type '=
array of type <code>void</code>' is formed while instantiating the body of =
a class template specialization, which is a non-immediate context. Expressi=
on <code>g(1)</code> is superficially ill-formed because an invalid type 'a=
rray of type <code>void</code>' would be formed in an immediate context. Ex=
pression <code>h(1)</code> is superficially well-formed because no invalid =
type or expression would be formed in the process of determining well-forme=
dness.
<i>— end example</i>]</p>
<p>[<i>Example:</i> Given the following definitions:<pre>
auto is_even =3D [](auto v) { return v % 2 =3D=3D 0; };
auto is_odd =3D [](auto v) -> decltype(v % 2 =3D=3D 1) { return v % 2 =
=3D=3D 1; };
</pre>
Expression <code>is_even(nullptr)</code> is deeply ill-formed because an in=
valid expression <code>nullptr % 2 =3D=3D 0</code> is formed while instanti=
ating the body of a function template specialization (for the purpose of de=
termining its return type), which is a non-immediate context. Expression <c=
ode>is_odd(nullptr)</code> is superficially ill-formed because an invalid e=
xpression <code>nullptr % 2 =3D=3D 1</code> would be formed in an immediate=
context.
<i>— end example</i>]</p>
<p>[<i>Example:</i> Given the following definitions:
<pre> template <class T> struct X {};
=20
template <typename T>
using XT =3D typename X<T>::type;
</pre>
Type <code>XT<int></code> is superficially ill-formed because an inva=
lid type <code>X<int>::type</code> would be formed inside an alias te=
mplate, which is an immediate context.
<i>— end example</i>]</p>
<p>[<i>Example:</i> Given the following definition:
<pre> struct S {
C(int);
C(double) =3D delete;
};
</pre>
Expression <code>C(0.5)</code> is superficially ill-formed because it is in=
immediate the context and it would cause the program to be ill-formed.
<i>— end example</i>]</p>
<p>Whenever in this clause it is stated that an expression <code>E</code> i=
s superficially well-formed for types <code>Tn</code>, there is an implied =
precondition that <code>E</code> is deeply well-formed for <code>Tn</code>.=
If this precondition is not satisfied, the program is ill-formed.</p>
</blockquote>
</li>
<li><p>Change 20.13.4.3 [meta.unary.prop], Table 52 — Type property p=
redicates, as indicated:</p>
<blockquote>
<table border=3D"1">
<caption>Table 52 — Type property predicates</caption>
<tr>
<th align=3D"center">Template</th>
<th align=3D"center">Condition</th>
<th align=3D"center">Preconditions</th>
</tr>
<tr>
<td colspan=3D"3" align=3D"center">
<tt>…</tt>
</td>
</tr>
<tr>
<td>
<tt>template <class T, class U><br/>
struct is_assignable;</tt>
</td>
<td>
The expression <tt>declval<T>() =3D declval<U>()</tt> is <ins>s=
uperficially</ins> well-formed when treated
as an unevaluated operand
(Clause 5). <del>Access checking
is performed as if in a
context unrelated to <code>T</code> and
<code>U</code>. Only the validity of the
immediate context of the
assignment expression is
considered. [<i>Note:</i> The
compilation of the
expression can result in
side effects such as the
instantiation of class
template specializations
and function template
specializations, the
generation of
implicitly-defined
functions, and so on. Such
side effects are not in the
“immediate context” and
can result in the program
being ill-formed. <i>— end
note</i>]</del>
</td>
<td>
<tt>T</tt> and <tt>U</tt> shall be complete types,<br/>=20
(possibly <i>cv</i>-qualified) <tt>void</tt>, or<br/>
arrays of unknown bound.
</td>
</tr>
<tr>
<td colspan=3D"3" align=3D"center">
<tt>…</tt>
</td>
</tr>
<tr>
<td>
<tt>template <class T, class U><br/>
struct is_swappable_with;</tt>
</td>
<td>
The expressions <tt>swap(declval<T>(), declval<U>())</tt> and<b=
r/>
<tt>swap(declval<U>(), declval<T>())</tt> are each <ins>superfi=
cially</ins> well-formed
when treated as an unevaluated operand (Clause 5) in an overload-resolution=
<br/>
context for swappable values (17.6.3.2 [swappable.requirements]). <del>Acce=
ss<br/>=20
checking is performed as if in a context unrelated to <tt>T</tt> and <tt>U<=
/tt>. Only the<br/>=20
validity of the immediate context of the <tt>swap</tt> expressions is consi=
dered.<br/>
[<i>Note</i>: The compilation of the expressions can result in side effects=
such<br/>
as the instantiation of class template specializations and function templat=
e<br/>
specializations, the generation of implicitly-defined functions, and so on.=
Such<br/>
side effects are not in the "immediate context" and can result in the progr=
am<br/>
being ill-formed. — <i>end note</i>]</del>
</td>
<td>
<tt>T</tt> and <tt>U</tt> shall be complete types,<br/>=20
(possibly <i>cv</i>-qualified) <tt>void</tt>, or<br/>
arrays of unknown bound.
</td>
</tr>
<tr>
<td colspan=3D"3" align=3D"center">
<tt>…</tt>
</td>
</tr>
</table>
</blockquote>
</li>
<li><p>In 20.13.4.3 [meta.unary.prop] change paragraph 8 as indicated:</p>
<blockquote>
The predicate condition for a template specialization <code>is_constructibl=
e<T, Args...></code> shall be satisfied if
and only if the following variable definition would be <ins>superficially</=
ins> well-formed for some invented variable <code>t</code>:
<pre> T t(declval<Args>()...);</pre>
[<i>Note:</i> These tokens are never interpreted as a function declaration.=
<i>— end note</i>] <del>Access checking is
performed as if in a context unrelated to <code>T</code> and any of the <co=
de>Args</code>. Only the validity of the immediate context
of the variable initialization is considered. [<i>Note:</i> The evaluation =
of the initialization can result in side
effects such as the instantiation of class template specializations and fun=
ction template specializations, the
generation of implicitly-defined functions, and so on. Such side effects ar=
e not in the =93immediate context=94
and can result in the program being ill-formed. <i>— end note</i>]</d=
el>
</blockquote>
</li>
<li><p>In 20.13.6 [meta.rel] change paragraph 5 as indicated:</p>
<blockquote>
The predicate condition for a template specialization <code>is_convertible&=
lt;From, To></code> shall be satisfied if
and only if the return expression in the following code would be <ins>super=
ficially</ins> well-formed, including any implicit conversions
to the return type of the function:
<pre>
To test() {
return declval<From>();
}</pre>
[<i>Note:</i> This requirement gives well defined results for reference typ=
es, void types, array types, and function
types. <i>— end note</i>]
<del>Access checking is performed as if in a context unrelated to <code>T</=
code> and any of the <code>Args</code>. Only the validity of the immediate =
context
of the variable initialization is considered. [<i>Note:</i> The evaluation =
of the initialization can result in side
effects such as the instantiation of class template specializations and fun=
ction template specializations, the
generation of implicitly-defined functions, and so on. Such side effects ar=
e not in the =93immediate context=94
and can result in the program being ill-formed. <i>— end note</i>]</d=
el>
</blockquote>
</li>
<li><p>Change 20.13.7.6 [meta.trans.other], Table 60 — Other transfor=
mations, as indicated:</p>
<blockquote>
<table border=3D"1">
<caption>Table 52 — Type property predicates</caption>
<tr>
<th align=3D"center">Template</th>
<th align=3D"center">Condition</th>
<th align=3D"center">Comments</th>
</tr>
<tr>
<td colspan=3D"3" align=3D"center">
<tt>…</tt>
</td>
</tr>
<tr>
<td>
<tt>template <class Fn,<br />
class... ArgTypes> struct<br />
result_of<Fn(ArgTypes...)>;</tt>
</td>
<td>
<code>Fn</code> and all types in the
parameter pack <code>ArgTypes</code>
shall be complete types,
(possibly cv-qualified) <code>void</code>,
or arrays of unknown bound.
</td>
<td>
If the expression
<code><i>INVOKE</i> (declval<Fn>(),
declval<ArgTypes>()...)</code> is <ins>superficially</ins> well<ins>-=
</ins>formed when treated as an unevaluated
operand (Clause 5), the member
typedef <code>type</code> shall name the type
<code>decltype(<i>INVOKE</i> (declval<Fn>(),
declval<ArgTypes>()...))</code>;
otherwise, there shall be no member
<code>type</code>. <del>Access checking is performed as
if in a context unrelated to <code>Fn</code> and
<code>ArgTypes</code>. Only the validity of the
immediate context of the expression is
considered. [<i>Note:</i> The compilation of
the expression can result in side effects
such as the instantiation of class
template specializations and function
template specializations, the
generation of implicitly-defined
functions, and so on. Such side effects
are not in the =93immediate context=94
and can result in the program being
ill-formed. <i>— end note</i>]</del>
</td>
</tr>
<tr>
<td colspan=3D"3" align=3D"center">
<tt>…</tt>
</td>
</tr>
</table>
</blockquote>
</li>
</ol> <!-- end of the list of changes-->
<!--<ol>
<li><p>Change 20.10.4.3 [meta.unary.prop], Table 49 — "Type property =
predicates", as indicated:</p>
<blockquote class=3D"note">
<p>
[<i>Drafting notes</i>:
</p>=20
<ol>
<li><p>
The term <i>referenceable type</i>, referred to below, is defined in 17.3.1=
9 [defns.referenceable].</p></li>
<li><p>The specification below allows, but does not require, that an implem=
entation defines the traits
<tt>is_swappable</tt> and <tt>is_nothrow_swappable</tt>, respectively, in t=
erms of the implementation details of the=20
more general traits <tt>is_swappable_with</tt> and <tt>is_nothrow_swappable=
_with</tt>, respectively.</p></li>
</ol>
<p>
— <i>end drafting notes</i>]
</p>
</blockquote>
</li>
</ol>-->
<h2>Acknowledgements</h2>
I am greatful to Tomasz Kamiński for helping me out with the wording, =
and clarifying the details of type deduction.
</body></html>
------=_Part_573_1961686176.1460122313363--
.