Topic: Deleted functions in template argument substitution
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Tue, 5 Apr 2016 05:37:26 -0700 (PDT)
Raw View
------=_Part_521_1055396583.1459859846988
Content-Type: multipart/alternative;
boundary="----=_Part_522_309251884.1459859846988"
------=_Part_522_309251884.1459859846988
Content-Type: text/plain; charset=UTF-8
Hi Everyone,
As outlined in this discussion
<https://groups.google.com/a/isocpp.org/d/topic/std-discussion/n0fjEpdugPg/discussion>,
it is not immediately clear how type traits should treat references to the
deleted functions. I enclose a proposal for wording changes that would make
this a bit more cleared. You can also see it online here
<https://htmlpreview.github.io/?https://github.com/akrzemi1/__sandbox__/blob/master/immediate_context.html>
..
I would like to ask people here experienced in writing and reviewing
proposals for feedback. Also, I wonder if a proposal that only clarifies
the wording should be submitted as a separate proposal, or as a defect
report with a suggested fix?
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/948cd1dc-c0d1-4dab-92f6-de3dd6ff707b%40isocpp.org.
------=_Part_522_309251884.1459859846988
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Everyone,<br>As outlined in <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/topic/std-discussion/n0fjEpdugPg/discussion">this =
discussion</a>, it is not immediately clear how type traits should treat re=
ferences to the deleted functions. I enclose a proposal for wording changes=
that would make this a bit more cleared. You can also see it online <a hre=
f=3D"https://htmlpreview.github.io/?https://github.com/akrzemi1/__sandbox__=
/blob/master/immediate_context.html">here</a>.<br><br>I would like to ask p=
eople here experienced in writing and reviewing proposals for feedback. Als=
o, I wonder if a proposal that only clarifies the wording should be submitt=
ed as a separate proposal, or as a defect report with a suggested fix?<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/948cd1dc-c0d1-4dab-92f6-de3dd6ff707b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/948cd1dc-c0d1-4dab-92f6-de3dd6ff707b=
%40isocpp.org</a>.<br />
------=_Part_522_309251884.1459859846988--
------=_Part_521_1055396583.1459859846988
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: ec1ef534-6f48-40f1-bb44-640431f415bb
Content-ID: <ec1ef534-6f48-40f1-bb44-640431f415bb>
<!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 two things:
<ol>
<li>How deleted functions are treated in SFINAE contexts.</li>
<li>What constitutes the "immediate context" during stemplate argument subs=
titution.</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>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>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_521_1055396583.1459859846988--
.
Author: "S.B." <i.and.my.little.friends@gmail.com>
Date: Tue, 5 Apr 2016 07:11:13 -0700 (PDT)
Raw View
------=_Part_555_417977575.1459865473417
Content-Type: multipart/alternative;
boundary="----=_Part_556_1954606354.1459865473418"
------=_Part_556_1954606354.1459865473418
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, April 5, 2016 at 8:37:27 PM UTC+8, Andrzej Krzemie=C5=84ski wro=
te:
>
> Hi Everyone,
> As outlined in this discussion=20
> <https://groups.google.com/a/isocpp.org/d/topic/std-discussion/n0fjEpdugP=
g/discussion>,=20
> it is not immediately clear how type traits should treat references to th=
e=20
> deleted functions. I enclose a proposal for wording changes that would ma=
ke=20
> this a bit more cleared. You can also see it online here=20
> <https://htmlpreview.github.io/?https://github.com/akrzemi1/__sandbox__/b=
lob/master/immediate_context.html>
> .
>
> I would like to ask people here experienced in writing and reviewing=20
> proposals for feedback. Also, I wonder if a proposal that only clarifies=
=20
> the wording should be submitted as a separate proposal, or as a defect=20
> report with a suggested fix?
>
> Regards,
> &rzej
>
I think the current P/R of LWG2290=20
<http://cplusplus.github.io/LWG/lwg-active.html#2290> is quite good. The=20
phrase "immediate context" is used in 14.8.2 [temp.deduct], so I think it=
=20
should better be defined there. The library sections could just reference=
=20
14.8.2 [temp.deduct].
--=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/3817d8eb-5a9a-498f-8ae0-55087060ce61%40isocpp.or=
g.
------=_Part_556_1954606354.1459865473418
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, April 5, 2016 at 8:37:27 PM UTC+8, And=
rzej Krzemie=C5=84ski wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr">Hi Everyone,<br>As outlined in <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/topic/std-discussion/n0fjEpdugPg/discussion" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups=
..google.com/a/isocpp.org/d/topic/std-discussion/n0fjEpdugPg/discussion'=
;return true;" onclick=3D"this.href=3D'https://groups.google.com/a/isoc=
pp.org/d/topic/std-discussion/n0fjEpdugPg/discussion';return true;">thi=
s discussion</a>, it is not immediately clear how type traits should treat =
references to the deleted functions. I enclose a proposal for wording chang=
es that would make this a bit more cleared. You can also see it online <a h=
ref=3D"https://htmlpreview.github.io/?https://github.com/akrzemi1/__sandbox=
__/blob/master/immediate_context.html" target=3D"_blank" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2=
Fhtmlpreview.github.io%2F%3Fhttps%3A%2F%2Fgithub.com%2Fakrzemi1%2F__sandbox=
__%2Fblob%2Fmaster%2Fimmediate_context.html\46sa\75D\46sntz\0751\46usg\75AF=
QjCNFkIwqg9rC2hMpGZcw1zd0Be5w15g';return true;" onclick=3D"this.href=3D=
'https://www.google.com/url?q\75https%3A%2F%2Fhtmlpreview.github.io%2F%=
3Fhttps%3A%2F%2Fgithub.com%2Fakrzemi1%2F__sandbox__%2Fblob%2Fmaster%2Fimmed=
iate_context.html\46sa\75D\46sntz\0751\46usg\75AFQjCNFkIwqg9rC2hMpGZcw1zd0B=
e5w15g';return true;">here</a>.<br><br>I would like to ask people here =
experienced in writing and reviewing proposals for feedback. Also, I wonder=
if a proposal that only clarifies the wording should be submitted as a sep=
arate proposal, or as a defect report with a suggested fix?<br><br>Regards,=
<br>&rzej<br></div></blockquote><div><br>I think the current P/R of=C2=
=A0<a href=3D"http://cplusplus.github.io/LWG/lwg-active.html#2290">LWG2290<=
/a> is quite good. The phrase "immediate context" is used in 14.8=
..2 [temp.deduct], so I think it should better be defined there. The library=
sections could just reference 14.8.2 [temp.deduct].<br></div></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/3817d8eb-5a9a-498f-8ae0-55087060ce61%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3817d8eb-5a9a-498f-8ae0-55087060ce61=
%40isocpp.org</a>.<br />
------=_Part_556_1954606354.1459865473418--
------=_Part_555_417977575.1459865473417--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Tue, 5 Apr 2016 07:31:48 -0700 (PDT)
Raw View
------=_Part_280_642107129.1459866708274
Content-Type: multipart/alternative;
boundary="----=_Part_281_1006040134.1459866708274"
------=_Part_281_1006040134.1459866708274
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu wtorek, 5 kwietnia 2016 16:11:13 UTC+2 u=C5=BCytkownik S.B. napisa=
=C5=82:
>
>
>
> On Tuesday, April 5, 2016 at 8:37:27 PM UTC+8, Andrzej Krzemie=C5=84ski w=
rote:
>>
>> Hi Everyone,
>> As outlined in this discussion=20
>> <https://groups.google.com/a/isocpp.org/d/topic/std-discussion/n0fjEpdug=
Pg/discussion>,=20
>> it is not immediately clear how type traits should treat references to t=
he=20
>> deleted functions. I enclose a proposal for wording changes that would m=
ake=20
>> this a bit more cleared. You can also see it online here=20
>> <https://htmlpreview.github.io/?https://github.com/akrzemi1/__sandbox__/=
blob/master/immediate_context.html>
>> .
>>
>> I would like to ask people here experienced in writing and reviewing=20
>> proposals for feedback. Also, I wonder if a proposal that only clarifies=
=20
>> the wording should be submitted as a separate proposal, or as a defect=
=20
>> report with a suggested fix?
>>
>> Regards,
>> &rzej
>>
>
> I think the current P/R of LWG2290=20
> <http://cplusplus.github.io/LWG/lwg-active.html#2290> is quite good. The=
=20
> phrase "immediate context" is used in 14.8.2 [temp.deduct], so I think it=
=20
> should better be defined there. The library sections could just reference=
=20
> 14.8.2 [temp.deduct].
>
Thank you for the link. Indeed, it addresses some of my concerns, but the=
=20
wording in LWG2290 <http://cplusplus.github.io/LWG/lwg-active.html#2290>=20
still does not help me answer whether how the deleted functions should be=
=20
treated.=20
--=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/f1d9d949-a73d-44f8-9ecf-ba842f5282c6%40isocpp.or=
g.
------=_Part_281_1006040134.1459866708274
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>W dniu wtorek, 5 kwietnia 2016 16:11:13 UTC+2 u=C5=
=BCytkownik S.B. napisa=C5=82:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><br><br>On Tuesday, April 5, 2016 at 8:37:27 PM UTC+8, And=
rzej Krzemie=C5=84ski wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr">Hi Everyone,<br>As outlined in <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/topic/std-discussion/n0fjEpdugPg/discussion" rel=3D"nofol=
low" target=3D"_blank" onmousedown=3D"this.href=3D'https://groups.googl=
e.com/a/isocpp.org/d/topic/std-discussion/n0fjEpdugPg/discussion';retur=
n true;" onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.org=
/d/topic/std-discussion/n0fjEpdugPg/discussion';return true;">this disc=
ussion</a>, it is not immediately clear how type traits should treat refere=
nces to the deleted functions. I enclose a proposal for wording changes tha=
t would make this a bit more cleared. You can also see it online <a href=3D=
"https://htmlpreview.github.io/?https://github.com/akrzemi1/__sandbox__/blo=
b/master/immediate_context.html" rel=3D"nofollow" target=3D"_blank" onmouse=
down=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fhtmlp=
review.github.io%2F%3Fhttps%3A%2F%2Fgithub.com%2Fakrzemi1%2F__sandbox__%2Fb=
lob%2Fmaster%2Fimmediate_context.html\46sa\75D\46sntz\0751\46usg\75AFQjCNFk=
Iwqg9rC2hMpGZcw1zd0Be5w15g';return true;" onclick=3D"this.href=3D'h=
ttps://www.google.com/url?q\75https%3A%2F%2Fhtmlpreview.github.io%2F%3Fhttp=
s%3A%2F%2Fgithub.com%2Fakrzemi1%2F__sandbox__%2Fblob%2Fmaster%2Fimmediate_c=
ontext.html\46sa\75D\46sntz\0751\46usg\75AFQjCNFkIwqg9rC2hMpGZcw1zd0Be5w15g=
';return true;">here</a>.<br><br>I would like to ask people here experi=
enced in writing and reviewing proposals for feedback. Also, I wonder if a =
proposal that only clarifies the wording should be submitted as a separate =
proposal, or as a defect report with a suggested fix?<br><br>Regards,<br>&a=
mp;rzej<br></div></blockquote><div><br>I think the current P/R of=C2=A0<a h=
ref=3D"http://cplusplus.github.io/LWG/lwg-active.html#2290" target=3D"_blan=
k" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/u=
rl?q\75http%3A%2F%2Fcplusplus.github.io%2FLWG%2Flwg-active.html%232290\46sa=
\75D\46sntz\0751\46usg\75AFQjCNE6tB_hnJ3qfoqM9bjHqMAF9w8mDg';return tru=
e;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2F=
cplusplus.github.io%2FLWG%2Flwg-active.html%232290\46sa\75D\46sntz\0751\46u=
sg\75AFQjCNE6tB_hnJ3qfoqM9bjHqMAF9w8mDg';return true;">LWG2290</a> is q=
uite good. The phrase "immediate context" is used in 14.8.2 [temp=
..deduct], so I think it should better be defined there. The library section=
s could just reference 14.8.2 [temp.deduct].<br></div></div></blockquote><d=
iv><br>Thank you for the link. Indeed, it addresses some of my concerns, bu=
t the wording in <a href=3D"http://cplusplus.github.io/LWG/lwg-active.html#=
2290" target=3D"_blank" rel=3D"nofollow">LWG2290</a> still does not help me=
answer whether how the deleted functions should be treated. </div></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/f1d9d949-a73d-44f8-9ecf-ba842f5282c6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f1d9d949-a73d-44f8-9ecf-ba842f5282c6=
%40isocpp.org</a>.<br />
------=_Part_281_1006040134.1459866708274--
------=_Part_280_642107129.1459866708274--
.