Topic: RFC: Allow class template specialisations in
Author: Tristan Brindle <tcbrindle@gmail.com>
Date: Sat, 29 Apr 2017 10:53:25 -0700 (PDT)
Raw View
------=_Part_748_1429502559.1493488405191
Content-Type: multipart/alternative;
boundary="----=_Part_749_257374684.1493488405192"
------=_Part_749_257374684.1493488405192
Content-Type: text/plain; charset=UTF-8
*tl;dr: to make structured binding (and other) customisation points easier
to implement, let's allow specialising*
*class templates in other **namespaces without leaving **the current
namespace, by fully-qualifying their names, i.e.:*
namespace my {
struct type { /* ... */ };
template <>
struct ::std::tuple_size<type> { /* ... */ };
// ^^ here
}
}
Motivation
Let's say I have a tuple-like type in my own namespace (constructor
constraints etc omitted for brevity):
namespace my {
template <typename... T>
struct tuple_like {
template <typename... U>
tuple_like(U&&... args) : items_(std::forward<U>(args)...) {}
private:
std::tuple<T...> items_;
};
/* ...other declarations in my namespace... */
}
Now, I wish to enable structured bindings usage in C++17. To do this, as well as implementing a get<I>() method
(or free function) in my own class or namespace, I need to specialise the std::tuple_size and std::tuple_element
classes. This involves leaving my own namespace an entering namespace std, before coming back to my own
namespace to continue with other declarations:
namespace my {
template <typename... T>
struct tuple_like {
template <typename... U>
tuple_like(U&& ... args)
: items_(std::forward<U>(args)...) {}
template <std::size_t I>
decltype(auto) get() const { return std::get<I>(items_); }
template <std::size_t I>
decltype(auto) get() { return std::get<I>(items_); }
private:
std::tuple<T...> items_;
};
} // close my namespace
namespace std {
template <typename... T>
struct tuple_size<my::tuple_like<T...>>
: integral_constant<std::size_t, sizeof...(T)> {};
template <size_t I, typename... T>
struct tuple_element<I, my::tuple_like<T...>>
: tuple_element<I, tuple<T...>> {};
}
} // close std namespace
namespace my { // re-enter my namespace
/* ...other declarations... */
}
Breaking out of my own namespace like this, adding some specialisations to namespace std, and then re-entering
my own namespace is messy; it breaks the "flow" of a header file. For this reason, specialisations like this are often
tucked away at the bottom of a header, far away from where they (logically) belong, and where they can easily be
overlooked during refactoring. With functions like get() and swap(), this is mitigated by the use of unqualified
calls and ADL, but for class specialisations like those required for structured bindings there is no alternative but to do
the namespace dance.
Proposal
What I'd like to suggest is to allow specialising types in an unrelated namespace by fully-qualifying the name of the type
being specialised, as in:
namespace my {
struct type { /* ... */ };
template <>
struct ::std::tuple_size<my::type>
// ^^ here
{
/* ... */
};
}
Impact on existing code
This syntax is, to the best of my knowledge, currently illegal, so there should be no issues with existing code.
Quick Questions
Q: Should we be able to use this syntax to *define* types in an unrelated namespace too?
A: No, that would lead to more of the sort of awkward spaghetti code we're trying to avoid. This should be strictly for
class template specialisations: the compiler must have seen a declaration of the base template beforehand.
Q: Inside the specialisation, are names from the enclosing namespace in scope?
A: Ideally, yes. I'd like to be able to have
namespace my {
template <>
struct ::std::tuple_size<type>
// ^^ here
{
/* ... */
};
}
as being equivalent to
} // exit my namespace
namespace std { // enter namespace std
using namespace my; // bring my names into scope
template <>
struct tuple_size<type> { /*... */ };
} // exit std namespace
namespace my { // re-enter my namespace
that is, names from both namespaces are available without qualification (except where required for disambiguation).
However, if this isn't possible or creates parsing problems, then requiring types from the surrounding namespace to
be qualified (i.e. as if the above using namespace declaration wasn't present)
doesn't seem to me that it would be too hard to learn or teach. It is exactly what we are required
to do today.
Q: Should we allow specialising function templates with this syntax too?
A: No, for two reasons. Firstly, the recommended way to implement function customisation points is to provide
an overload in one's own namespace. Allowing this syntax for functions would encourage placing specialisations
in namespace std instead. Secondly, the syntax
template <>
my_type ::unrelated_ns::func<my_type>(const my_type& arg);
looks to the compiler (and to a human at a quick glance) like my_type::unrelated_ns::func, i.e. whitespace is
ignored before the double colon. We could get around this by saying that such specialisations must use the
trailing-return syntax (because auto::unrelated::func() is never correct AFAIK), but adding
such a special case to parsing doesn't seem worth the benefit since, again, there is much less need to specialise
function templates in other namespaces compared with classes.
Summary
Allowing this small syntax change strictly for providing class template specialisations in unrelated namespaces will reduce
spaghetti code in headers/modules and make structured bindings support easier and cleaner to implement.
We should allow it in C++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 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/5bd1ff39-eb86-4d46-b75a-99cc80f8f114%40isocpp.org.
------=_Part_749_257374684.1493488405192
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br></div><div><i>tl;dr: to make structured binding (=
and other) customisation points easier to implement, let's allow specia=
lising</i></div><div><i>class templates in other=C2=A0</i><i>namespaces wit=
hout leaving=C2=A0</i><i>the current namespace, by fully-qualifying their n=
ames, i.e.:</i></div><div><br></div><div><pre style=3D"color: rgb(0, 0, 0);=
font-family: Menlo; font-size: 9pt;"><pre style=3D"font-family: Menlo; fon=
t-size: 9pt;"><span style=3D"color:#000080;font-weight:bold;">namespace </s=
pan>my {<br><br><span style=3D"color:#000080;font-weight:bold;">struct </sp=
an>type { <span style=3D"color:#808080;font-style:italic;">/* ... */ </span=
>};<br><br><span style=3D"color:#000080;font-weight:bold;">template </span>=
<><br><span style=3D"color:#000080;font-weight:bold;">struct </span>:=
:std::tuple_size<type> { <span style=3D"color:#808080;font-style:ital=
ic;">/* ... */ </span>};<br><span style=3D"color:#808080;font-style:italic;=
">// ^^ here<br></span><span style=3D"color:#808080;font-style:italic;"=
><br></span>}<br><br>}</pre><pre style=3D"font-family: Menlo; font-size: 9p=
t;"><br></pre><pre style=3D"font-family: Menlo; font-size: 9pt;"><br></pre>=
</pre></div><div><font size=3D"4">Motivation</font></div><div><font face=3D=
"arial, sans-serif"><br></font></div><font face=3D"arial, sans-serif">Let&#=
39;s say I have a tuple-like type in my own namespace (constructor constrai=
nts etc omitted for brevity):</font><div><div><br></div><div><pre style=3D"=
color: rgb(0, 0, 0); font-family: Menlo; font-size: 9pt;"><pre style=3D"fon=
t-family: Menlo; font-size: 9pt;"><span style=3D"color:#000080;font-weight:=
bold;">namespace </span>my {<br><br><span style=3D"color:#000080;font-weigh=
t:bold;">template </span><<span style=3D"color:#000080;font-weight:bold;=
">typename</span>... T><br><span style=3D"color:#000080;font-weight:bold=
;">struct </span>tuple_like {<br> <span style=3D"color:#000080;font-weig=
ht:bold;">template </span><<span style=3D"color:#000080;font-weight:bold=
;">typename</span>... U><br> tuple_like(U&&... <span style=3D=
"color:#660e7a;font-weight:bold;font-style:italic;">args</span>) : items_(s=
td::forward<U>(<span style=3D"color:#660e7a;font-weight:bold;font-sty=
le:italic;">args</span>)...) {}<br><br><span style=3D"color:#000080;font-we=
ight:bold;">private</span>:<br> std::tuple<T...> items_;<br>};<br>=
<br><span style=3D"color:#808080;font-style:italic;">/* ...other declaratio=
ns in my namespace... */<br></span><span style=3D"color:#808080;font-style:=
italic;"><br></span>}<br></pre></pre><pre style=3D"color: rgb(0, 0, 0); fon=
t-size: 9pt;"><font face=3D"arial, sans-serif"><br></font></pre><pre style=
=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=3D"arial, sans-serif">=
Now, I wish to enable structured bindings usage in C++17. To do this, as we=
ll as implementing a </font><font face=3D"courier new, monospace">get<I&=
gt;() </font><font face=3D"arial, sans-serif">method</font></pre><pre style=
=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=3D"arial, sans-serif">=
(or free function) in my own class or namespace, I need to specialise the <=
/font><font face=3D"courier new, monospace">std::tuple_size</font><font fac=
e=3D"arial, sans-serif"> and </font><font face=3D"courier new, monospace">s=
td::tuple_element</font></pre><pre style=3D"color: rgb(0, 0, 0); font-size:=
9pt;"><font face=3D"arial, sans-serif">classes. This involves leaving my o=
wn namespace an entering namespace std, before coming back to my own</font>=
</pre><pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=3D"ari=
al, sans-serif">namespace to continue with other declarations:</font></pre>=
<pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=3D"arial, sa=
ns-serif"><br></font></pre><pre style=3D"color: rgb(0, 0, 0); font-size: 9p=
t;"><pre style=3D"font-family: Menlo; font-size: 9pt;"><span style=3D"color=
:#000080;font-weight:bold;">namespace </span>my {<br><br><span style=3D"col=
or:#000080;font-weight:bold;">template </span><<span style=3D"color:#000=
080;font-weight:bold;">typename</span>... T><br><span style=3D"color:#00=
0080;font-weight:bold;">struct </span>tuple_like {<br> <span style=3D"co=
lor:#000080;font-weight:bold;">template </span><<span style=3D"color:#00=
0080;font-weight:bold;">typename</span>... U><br> tuple_like(U&&a=
mp; ... <span style=3D"color:#660e7a;font-weight:bold;font-style:italic;">a=
rgs</span>)<br> : items_(std::forward<U>(<span style=3D"co=
lor:#660e7a;font-weight:bold;font-style:italic;">args</span>)...) {}<br><br=
> <span style=3D"color:#000080;font-weight:bold;">template </span><st=
d::size_t I><br> <span style=3D"color:#000080;font-weight:bold;">decl=
type</span>(<span style=3D"color:#000080;font-weight:bold;">auto</span>) ge=
t() <span style=3D"color:#000080;font-weight:bold;">const </span>{ <span st=
yle=3D"color:#000080;font-weight:bold;">return </span>std::get<I>(ite=
ms_); }<br><br> <span style=3D"color:#000080;font-weight:bold;">template=
</span><std::size_t I><br> <span style=3D"color:#000080;font-weig=
ht:bold;">decltype</span>(<span style=3D"color:#000080;font-weight:bold;">a=
uto</span>) get() { <span style=3D"color:#000080;font-weight:bold;">return =
</span>std::get<I>(items_); }<br><br><br><span style=3D"color:#000080=
;font-weight:bold;">private</span>:<br> std::tuple<T...> items_;<b=
r>};<br><br>} <span style=3D"color:#808080;font-style:italic;">// close my =
namespace<br></span><span style=3D"color:#808080;font-style:italic;"><br></=
span><span style=3D"color:#000080;font-weight:bold;">namespace </span>std {=
<br><br><span style=3D"color:#000080;font-weight:bold;">template </span><=
;<span style=3D"color:#000080;font-weight:bold;">typename</span>... T><b=
r><span style=3D"color:#000080;font-weight:bold;">struct </span>tuple_size&=
lt;my::tuple_like<T...>><br> : integral_constant<std::si=
ze_t, <span style=3D"color:#000080;font-weight:bold;">sizeof</span>...(T)&g=
t; {};<br><br><span style=3D"color:#000080;font-weight:bold;">template </sp=
an><size_t I, <span style=3D"color:#000080;font-weight:bold;">typename</=
span>... T><br><span style=3D"color:#000080;font-weight:bold;">struct </=
span>tuple_element<I, my::tuple_like<T...>><br> : tuple_=
element<I, tuple<T...>> {};<br><br>}<br><br>} <span style=3D"co=
lor:#808080;font-style:italic;">// close std namespace<br></span><span styl=
e=3D"color:#808080;font-style:italic;"><br></span><span style=3D"color:#000=
080;font-weight:bold;">namespace </span>my { <span style=3D"color:#808080;f=
ont-style:italic;">// re-enter my namespace<br></span><span style=3D"color:=
#808080;font-style:italic;"><br></span><span style=3D"color:#808080;font-st=
yle:italic;">/* ...other declarations... */<br></span><span style=3D"color:=
#808080;font-style:italic;"><br></span>}</pre></pre><pre style=3D"color: rg=
b(0, 0, 0); font-size: 9pt;"><font face=3D"arial, sans-serif"><br></font></=
pre><pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><br></pre><pre styl=
e=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=3D"arial, sans-serif"=
>Breaking out of my own namespace like this, adding some specialisations to=
namespace </font><font face=3D"courier new, monospace">std</font><font fac=
e=3D"arial, sans-serif">, and then re-entering</font></pre><pre style=3D"co=
lor: rgb(0, 0, 0); font-size: 9pt;"><font face=3D"arial, sans-serif">my own=
namespace is messy; it breaks the "flow" of a header file. For t=
his reason, specialisations like this are often</font></pre><pre style=3D"c=
olor: rgb(0, 0, 0); font-size: 9pt;"><font face=3D"arial, sans-serif">tucke=
d away at the bottom of a header, far away from where they (logically) belo=
ng, and where they can easily be</font></pre><pre style=3D"color: rgb(0, 0,=
0); font-size: 9pt;"><font face=3D"arial, sans-serif">overlooked during re=
factoring. With functions like </font><font face=3D"courier new, monospace"=
>get()</font><font face=3D"arial, sans-serif"> and </font><font face=3D"cou=
rier new, monospace">swap()</font><font face=3D"arial, sans-serif">, this i=
s mitigated by the use of unqualified</font></pre><pre style=3D"color: rgb(=
0, 0, 0); font-size: 9pt;"><font face=3D"arial, sans-serif">calls and ADL, =
but for class specialisations like those required for structured bindings t=
here is no alternative but to do</font></pre><pre style=3D"color: rgb(0, 0,=
0); font-size: 9pt;"><font face=3D"arial, sans-serif">the namespace dance.=
</font></pre><pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=
=3D"arial, sans-serif"><br></font></pre><pre style=3D"color: rgb(0, 0, 0);"=
><font face=3D"arial, sans-serif" size=3D"4">Proposal</font></pre><pre styl=
e=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=3D"arial, sans-serif"=
><br></font></pre><pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font=
face=3D"arial, sans-serif">What I'd like to suggest is to allow specia=
lising types in an unrelated namespace by fully-qualifying the name of the =
type</font></pre><pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font =
face=3D"arial, sans-serif">being specialised, as in:</font></pre><pre style=
=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=3D"arial, sans-serif">=
<br></font></pre><pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><pre s=
tyle=3D"font-size: 9pt; font-family: Menlo;"><pre style=3D"font-family: Men=
lo; font-size: 9pt;"><span style=3D"color:#000080;font-weight:bold;">namesp=
ace </span>my {<br><br><span style=3D"color:#000080;font-weight:bold;">stru=
ct </span>type { <span style=3D"color:#808080;font-style:italic;">/* ... */=
</span>};<br><br><span style=3D"color:#000080;font-weight:bold;">template =
</span><><br><span style=3D"color:#000080;font-weight:bold;">struct <=
/span>::std::tuple_size<my::type><br><span style=3D"color:#808080;fon=
t-style:italic;">// ^^ here<br></span>{<br> <span style=3D"color:#80=
8080;font-style:italic;">/* ... */<br></span>};<br><br>}</pre></pre></pre><=
pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-serif" size=3D=
"4"><br></font></pre><pre style=3D"color: rgb(0, 0, 0);"><font face=3D"aria=
l, sans-serif" size=3D"4">Impact on existing code</font></pre><pre style=3D=
"color: rgb(0, 0, 0); font-size: 9pt;"><font face=3D"arial, sans-serif"><br=
></font></pre><pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font fac=
e=3D"arial, sans-serif">This syntax is, to the best of my knowledge, curren=
tly illegal, so there should be no issues with existing code.</font></pre><=
pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=3D"arial, san=
s-serif"><br></font></pre><pre style=3D"color: rgb(0, 0, 0);"><font face=3D=
"arial, sans-serif" size=3D"4">Quick Questions</font></pre><pre style=3D"co=
lor: rgb(0, 0, 0);"><font face=3D"arial, sans-serif"><br></font></pre><pre =
style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-serif">Q: Should w=
e be able to use this syntax to <i>define</i> types in an unrelated namespa=
ce too?</font></pre><pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial=
, sans-serif"><br></font></pre><pre style=3D"color: rgb(0, 0, 0);"><font fa=
ce=3D"arial, sans-serif"><font color=3D"#000000"><span style=3D"font-size: =
12px;">A: No, that would lead to more of the sort of awkward spaghetti code=
we're trying to avoid. </span></font><span style=3D"color: rgb(34, 34,=
34);">This should be strictly for</span></font></pre><pre style=3D"color: =
rgb(0, 0, 0);"><font face=3D"arial, sans-serif"><span style=3D"color: rgb(3=
4, 34, 34);">class template specialisations: the compiler must have seen a =
declaration of the base template beforehand.</span></font></pre><pre style=
=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-serif"><span style=3D"c=
olor: rgb(34, 34, 34);"><br></span></font></pre><pre style=3D"color: rgb(0,=
0, 0);"><pre><font face=3D"arial, sans-serif">Q: Inside the specialisation=
, are names from the enclosing namespace in scope?</font></pre><pre><font f=
ace=3D"arial, sans-serif"><br></font></pre><pre><font face=3D"arial, sans-s=
erif">A: Ideally, yes. I'd like to be able to have</font></pre><pre><fo=
nt face=3D"arial, sans-serif"><br></font></pre><pre><pre style=3D"font-size=
: 9pt; font-family: Menlo;"><span style=3D"color: rgb(0, 0, 128); font-weig=
ht: bold;">namespace </span>my {<br><br><span style=3D"color: rgb(0, 0, 128=
); font-weight: bold;">template </span><><br><span style=3D"color: rg=
b(0, 0, 128); font-weight: bold;">struct </span>::std::tuple_size<type&g=
t;<br><span style=3D"color: rgb(128, 128, 128); font-style: italic;">// =
^^ here<br></span>{<br> <span style=3D"color: rgb(128, 128, 128); font-=
style: italic;">/* ... */<br></span>};<br><br>}</pre></pre><pre><font face=
=3D"arial, sans-serif"><br></font></pre><pre><font face=3D"arial, sans-seri=
f">as being equivalent to</font></pre><pre><font face=3D"arial, sans-serif"=
><br></font></pre><pre><pre style=3D"font-family: Menlo; font-size: 9pt;">}=
<span style=3D"color:#808080;font-style:italic;">// exit my namespace<br><=
/span><span style=3D"color:#808080;font-style:italic;"><br></span><span sty=
le=3D"color:#000080;font-weight:bold;">namespace </span>std { <span style=
=3D"color:#808080;font-style:italic;">// enter namespace std<br></span><spa=
n style=3D"color:#808080;font-style:italic;"><br></span><span style=3D"colo=
r:#000080;font-weight:bold;">using namespace </span>my; <span style=3D"colo=
r:#808080;font-style:italic;">// bring my names into scope<br></span><span =
style=3D"color:#808080;font-style:italic;"><br></span><span style=3D"color:=
#000080;font-weight:bold;">template </span><><br><span style=3D"color=
:#000080;font-weight:bold;">struct </span>tuple_size<type> { <span st=
yle=3D"color:#808080;font-style:italic;">/*... */ </span>};<br><br>} <span =
style=3D"color:#808080;font-style:italic;">// exit std namespace<br></span>=
<span style=3D"color:#808080;font-style:italic;"><br></span><span style=3D"=
color:#000080;font-weight:bold;">namespace </span>my { <span style=3D"color=
:#808080;font-style:italic;">// re-enter my namespace</span></pre></pre><pr=
e><font face=3D"arial, sans-serif"><br></font></pre><pre><font face=3D"aria=
l, sans-serif">that is, names from both namespaces are available without qu=
alification (except where required for disambiguation).</font></pre><pre><f=
ont face=3D"arial, sans-serif">However, if this isn't possible or creat=
es parsing problems, then requiring types from the surrounding namespace to=
</font></pre><pre><font face=3D"arial, sans-serif">be qualified (i.e. as if=
the above </font><font face=3D"courier new, monospace">using namespace</f=
ont><font face=3D"arial, sans-serif"> declaration wasn't present)</font=
></pre><pre><font face=3D"arial, sans-serif">doesn't seem to me that it=
would be too hard to learn or teach. It is exactly what we are required</f=
ont></pre><pre><font face=3D"arial, sans-serif">to do today.</font></pre><p=
re><br></pre></pre><pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial,=
sans-serif"><span style=3D"color: rgb(34, 34, 34);">Q: Should we allow spe=
cialising function templates with this syntax too?</span></font></pre><pre =
style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-serif"><span style=
=3D"color: rgb(34, 34, 34);"><br></span></font></pre><pre style=3D"color: r=
gb(0, 0, 0);"><font face=3D"arial, sans-serif"><span style=3D"color: rgb(34=
, 34, 34);">A: No, for two reasons. Firstly, the recommended way to impleme=
nt function customisation points is to provide<br></span></font></pre><pre =
style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-serif"><span style=
=3D"color: rgb(34, 34, 34);">an overload in one's own namespace. Allowi=
ng this syntax for functions would encourage placing specialisations</span>=
</font></pre><pre style=3D"color: rgb(0, 0, 0);"><span style=3D"color: rgb(=
34, 34, 34);"><font face=3D"arial, sans-serif">in namespace</font><font fac=
e=3D"courier new, monospace"> std</font><font face=3D"arial, sans-serif"> i=
nstead. Secondly, the syntax</font></span></pre><pre style=3D"color: rgb(0,=
0, 0);"><font face=3D"arial, sans-serif"><span style=3D"color: rgb(34, 34,=
34);"><br></span></font></pre><pre style=3D"color: rgb(0, 0, 0);"><pre sty=
le=3D"font-family: Menlo; font-size: 9pt;"><span style=3D"color:#000080;fon=
t-weight:bold;">template </span><><br>my_type ::unrelated_ns::func<=
;my_type>(<span style=3D"color:#000080;font-weight:bold;">const </span>m=
y_type& <span style=3D"color:#660e7a;font-weight:bold;font-style:italic=
;">arg</span>);</pre></pre><pre style=3D"color: rgb(0, 0, 0);"><br></pre><p=
re style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-serif">looks to=
the compiler (and to a human at a quick glance) like </font><font face=3D"=
courier new, monospace">my_type::unrelated_ns::func</font><font face=3D"ari=
al, sans-serif">, i.e. whitespace is</font></pre><pre style=3D"color: rgb(0=
, 0, 0);"><font face=3D"arial, sans-serif">ignored before the double colon.=
We could get around this by saying that such specialisations must use the<=
/font></pre><pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-s=
erif">trailing-return syntax (because </font><font face=3D"courier new, mon=
ospace">auto::unrelated::func()</font><font face=3D"arial, sans-serif"> is =
never correct AFAIK), but adding</font></pre><pre style=3D"color: rgb(0, 0,=
0);"><font face=3D"arial, sans-serif">such a special case to parsing doesn=
't seem worth the benefit since, again, there is much less need to spec=
ialise</font></pre><pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial,=
sans-serif">function templates in other namespaces compared with classes.<=
/font></pre><pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-s=
erif"><br></font></pre><pre style=3D"color: rgb(0, 0, 0);"><br></pre><pre s=
tyle=3D"color: rgb(0, 0, 0);"><font size=3D"4" face=3D"arial, sans-serif">S=
ummary</font></pre><pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial,=
sans-serif"><br></font></pre><pre style=3D"color: rgb(0, 0, 0);"><font fac=
e=3D"arial, sans-serif">Allowing this small syntax change strictly for prov=
iding class template specialisations in unrelated namespaces will reduce</f=
ont></pre><pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-ser=
if">spaghetti code in headers/modules and make structured bindings support =
easier and cleaner to implement.</font></pre><pre style=3D"color: rgb(0, 0,=
0);"><font face=3D"arial, sans-serif">We should allow it in C++20 :).</fon=
t></pre><pre style=3D"color: rgb(0, 0, 0);"><br></pre><pre style=3D"color: =
rgb(0, 0, 0);"><br></pre></div></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/5bd1ff39-eb86-4d46-b75a-99cc80f8f114%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5bd1ff39-eb86-4d46-b75a-99cc80f8f114=
%40isocpp.org</a>.<br />
------=_Part_749_257374684.1493488405192--
------=_Part_748_1429502559.1493488405191--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Sat, 29 Apr 2017 15:00:50 -0700 (PDT)
Raw View
------=_Part_934_1725094660.1493503250250
Content-Type: multipart/alternative;
boundary="----=_Part_935_539571590.1493503250250"
------=_Part_935_539571590.1493503250250
Content-Type: text/plain; charset=UTF-8
+1, I like it! For my part: Go for it!
Another use case beside structured bindings and tuple-like interface is
overloading std::hash<T> for example.
Cheers,
Jakob
--
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/831c33bf-a4c4-4491-8578-2361e9a3b5b0%40isocpp.org.
------=_Part_935_539571590.1493503250250
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">+1, I like it! For my part: Go for it!<div><br></div><div>=
Another use case beside structured bindings and tuple-like interface is ove=
rloading std::hash<T> for example.</div><div><br></div><div>Cheers,</=
div><div>Jakob</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/831c33bf-a4c4-4491-8578-2361e9a3b5b0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/831c33bf-a4c4-4491-8578-2361e9a3b5b0=
%40isocpp.org</a>.<br />
------=_Part_935_539571590.1493503250250--
------=_Part_934_1725094660.1493503250250--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sun, 30 Apr 2017 00:25:04 +0200
Raw View
This is a multi-part message in MIME format.
--------------7BEDFE81379B7325D0C80DA1
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 29/04/2017 =C3=A0 19:53, Tristan Brindle a =C3=A9crit :
>
> /tl;dr: to make structured binding (and other) customisation points=20
> easier to implement, let's allow specialising/
> /class templates in other //namespaces without leaving //the current=20
> namespace, by fully-qualifying their names, i.e.:/
>
> namespace my {
>
> struct type {/* ... */ };
>
> template <>
> struct ::std::tuple_size<type> {/* ... */ };
> // ^^ here }
>
> }
I'm all for this. I need it for my alternative customization point proposal=
..
This was already proposed long time ago together with a another feature.
You can take a look at [N1691] Explicit Namespaces
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1691.html
The proposal contains:
* explicit namespaces (I need something like this also ;-)
* something like your proposal
The use case I have from your proposal are mixins. We can define a=20
friend function from a mixin, but we can not specialize a trait. Having=20
this possibility could make much powerful the use mixins.
> Motivation
>
> Let's say I have a tuple-like type in my own namespace (constructor=20
> constraints etc omitted for brevity):
>
> namespace my {
>
> template <typename... T>
> struct tuple_like {
> template <typename... U>
> tuple_like(U&&...args) : items_(std::forward<U>(args)...) {}
>
> private:
> std::tuple<T...> items_;
> };
>
> /* ...other declarations in my namespace... */ }
> Now, I wish to enable structured bindings usage in C++17. To do this,=20
> as well as implementing a get<I>() method
> (or free function) in my own class or namespace, I need to specialise=20
> the std::tuple_sizeand std::tuple_element
> classes. This involves leaving my own namespace an entering namespace=20
> std, before coming back to my own
> namespace to continue with other declarations:
> namespace my {
>
> template <typename... T>
> struct tuple_like {
> template <typename... U>
> tuple_like(U&& ...args)
> : items_(std::forward<U>(args)...) {}
>
> template <std::size_t I>
> decltype(auto) get()const {return std::get<I>(items_); }
>
> template <std::size_t I>
> decltype(auto) get() {return std::get<I>(items_); }
>
>
> private:
> std::tuple<T...> items_;
> };
>
> }// close my namespace namespace std {
>
> template <typename... T>
> struct tuple_size<my::tuple_like<T...>>
> : integral_constant<std::size_t,sizeof...(T)> {};
>
> template <size_t I,typename... T>
> struct tuple_element<I, my::tuple_like<T...>>
> : tuple_element<I, tuple<T...>> {};
>
> }
>
> }// close std namespace namespace my {// re-enter my namespace /* ...othe=
r declarations... */ }
> Breaking out of my own namespace like this, adding some=20
> specialisations to namespace std, and then re-entering
> my own namespace is messy; it breaks the "flow" of a header file. For=20
> this reason, specialisations like this are often
> tucked away at the bottom of a header, far away from where they=20
> (logically) belong, and where they can easily be
> overlooked during refactoring. With functions like get()and swap(),=20
> this is mitigated by the use of unqualified
> calls and ADL, but for class specialisations like those required for=20
> structured bindings there is no alternative but to do
> the namespace dance.
> Proposal
> What I'd like to suggest is to allow specialising types in an=20
> unrelated namespace by fully-qualifying the name of the type
> being specialised, as in:
> namespace my {
>
> struct type {/* ... */ };
>
> template <>
> struct ::std::tuple_size<my::type>
> // ^^ here {
> /* ... */ };
>
> }
> Impact on existing code
> This syntax is, to the best of my knowledge, currently illegal, so=20
> there should be no issues with existing code.
> Quick Questions
> Q: Should we be able to use this syntax to /define/ types in an=20
> unrelated namespace too?
> A: No, that would lead to more of the sort of awkward spaghetti code=20
> we're trying to avoid. This should be strictly for
> class template specialisations: the compiler must have seen a=20
> declaration of the base template beforehand.
I agree.
> Q: Inside the specialisation, are names from the enclosing namespace=20
> in scope?
> A: Ideally, yes. I'd like to be able to have
> namespace my {
>
> template <>
> struct ::std::tuple_size<type>
> // ^^ here {
> /* ... */ };
>
> }
> as being equivalent to
> }// exit my namespace namespace std {// enter namespace std using namespa=
ce my;// bring my names into scope template <>
> struct tuple_size<type> {/*... */ };
>
> }// exit std namespace namespace my {// re-enter my namespace
> that is, names from both namespaces are available without=20
> qualification (except where required for disambiguation).
> However, if this isn't possible or creates parsing problems, then=20
> requiring types from the surrounding namespace to
> be qualified (i.e. as if the above using namespacedeclaration wasn't=20
> present)
> doesn't seem to me that it would be too hard to learn or teach. It is=20
> exactly what we are required
> to do today.
For coherency as you are in your namespace it seems natural to be able=20
to use anything is in scope.
> Q: Should we allow specialising function templates with this syntax too?
> A: No, for two reasons. Firstly, the recommended way to implement=20
> function customisation points is to provide
> an overload in one's own namespace. Allowing this syntax for functions=20
> would encourage placing specialisations
> in namespacestdinstead. Secondly, the syntax
> template <>
> my_type ::unrelated_ns::func<my_type>(const my_type&arg);
> looks to the compiler (and to a human at a quick glance) like=20
> my_type::unrelated_ns::func, i.e. whitespace is
> ignored before the double colon. We could get around this by saying=20
> that such specialisations must use the
> trailing-return syntax (because auto::unrelated::func()is never=20
> correct AFAIK), but adding
> such a special case to parsing doesn't seem worth the benefit since,=20
> again, there is much less need to specialise
> function templates in other namespaces compared with classes.
See [N1295]
Partial specialization of function templates
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2001/n1295.asc
> Summary
> Allowing this small syntax change strictly for providing class=20
> template specialisations in unrelated namespaces will reduce
> spaghetti code in headers/modules and make structured bindings support=20
> easier and cleaner to implement.
> We should allow it in C++20 :).
I don't know what where the reasons this old proposal was not followed.
I think it is worth trying it again.
Vicente
--=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/52c31d25-c82f-09b3-e37b-c1e7e8e3ffc7%40wanadoo.f=
r.
--------------7BEDFE81379B7325D0C80DA1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 29/04/2017 =C3=A0 19:53, Tristan Brin=
dle
a =C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:5bd1ff39-eb86-4d46-b75a-99cc80f8f114@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<div><i>tl;dr: to make structured binding (and other)
customisation points easier to implement, let's allow
specialising</i></div>
<div><i>class templates in other=C2=A0</i><i>namespaces without
leaving=C2=A0</i><i>the current namespace, by fully-qualifying
their names, i.e.:</i></div>
<div><br>
</div>
<div>
<pre style=3D"color: rgb(0, 0, 0); font-family: Menlo; font-size:=
9pt;"><pre style=3D"font-family: Menlo; font-size: 9pt;"><span style=3D"co=
lor:#000080;font-weight:bold;">namespace </span>my {
<span style=3D"color:#000080;font-weight:bold;">struct </span>type { <span =
style=3D"color:#808080;font-style:italic;">/* ... */ </span>};
<span style=3D"color:#000080;font-weight:bold;">template </span><>
<span style=3D"color:#000080;font-weight:bold;">struct </span>::std::tuple_=
size<type> { <span style=3D"color:#808080;font-style:italic;">/* ... =
*/ </span>};
<span style=3D"color:#808080;font-style:italic;">// ^^ here
</span><span style=3D"color:#808080;font-style:italic;">
</span>}
}</pre><pre style=3D"font-family: Menlo; font-size: 9pt;">
</pre></pre>
</div>
</div>
</blockquote>
I'm all for this. I need it for my alternative customization point
proposal.<br>
This was already proposed long time ago together with a another
feature.<br>
You can take a look at [N1691] Explicit Namespaces <br>
<a class=3D"moz-txt-link-freetext" href=3D"http://www.open-std.org/jtc1=
/sc22/wg21/docs/papers/2004/n1691.html">http://www.open-std.org/jtc1/sc22/w=
g21/docs/papers/2004/n1691.html</a><br>
<br>
The proposal contains:<br>
* explicit namespaces (I need something like this also ;-)<br>
* something like your proposal<br>
<br>
<br>
The use case I have from your proposal are mixins. We can define a
friend function from a mixin, but we can not specialize a trait.
Having this possibility could make much powerful the use mixins.<br>
<br>
<br>
<br>
<blockquote
cite=3D"mid:5bd1ff39-eb86-4d46-b75a-99cc80f8f114@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>
<pre style=3D"color: rgb(0, 0, 0); font-family: Menlo; font-size:=
9pt;"><pre style=3D"font-family: Menlo; font-size: 9pt;">
</pre></pre>
</div>
<div><font size=3D"4">Motivation</font></div>
<div><font face=3D"arial, sans-serif"><br>
</font></div>
<font face=3D"arial, sans-serif">Let's say I have a tuple-like
type in my own namespace (constructor constraints etc omitted
for brevity):</font>
<div>
<div><br>
</div>
<div>
<pre style=3D"color: rgb(0, 0, 0); font-family: Menlo; font-siz=
e: 9pt;"><pre style=3D"font-family: Menlo; font-size: 9pt;"><span style=3D"=
color:#000080;font-weight:bold;">namespace </span>my {
<span style=3D"color:#000080;font-weight:bold;">template </span><<span s=
tyle=3D"color:#000080;font-weight:bold;">typename</span>... T>
<span style=3D"color:#000080;font-weight:bold;">struct </span>tuple_like {
<span style=3D"color:#000080;font-weight:bold;">template </span><<sp=
an style=3D"color:#000080;font-weight:bold;">typename</span>... U>
tuple_like(U&&... <span style=3D"color:#660e7a;font-weight:bold=
;font-style:italic;">args</span>) : items_(std::forward<U>(<span styl=
e=3D"color:#660e7a;font-weight:bold;font-style:italic;">args</span>)...) {}
<span style=3D"color:#000080;font-weight:bold;">private</span>:
std::tuple<T...> items_;
};
<span style=3D"color:#808080;font-style:italic;">/* ...other declarations i=
n my namespace... */
</span><span style=3D"color:#808080;font-style:italic;">
</span>}
</pre></pre>
<pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=
=3D"arial, sans-serif">
</font></pre>
<pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=
=3D"arial, sans-serif">Now, I wish to enable structured bindings usage in C=
++17. To do this, as well as implementing a </font><font face=3D"courier ne=
w, monospace">get<I>() </font><font face=3D"arial, sans-serif">method=
</font></pre>
<pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=
=3D"arial, sans-serif">(or free function) in my own class or namespace, I n=
eed to specialise the </font><font face=3D"courier new, monospace">std::tup=
le_size</font><font face=3D"arial, sans-serif"> and </font><font face=3D"co=
urier new, monospace">std::tuple_element</font></pre>
<pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=
=3D"arial, sans-serif">classes. This involves leaving my own namespace an e=
ntering namespace std, before coming back to my own</font></pre>
<pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=
=3D"arial, sans-serif">namespace to continue with other declarations:</font=
></pre>
<pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=
=3D"arial, sans-serif">
</font></pre>
<pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><pre style=
=3D"font-family: Menlo; font-size: 9pt;"><span style=3D"color:#000080;font-=
weight:bold;">namespace </span>my {
<span style=3D"color:#000080;font-weight:bold;">template </span><<span s=
tyle=3D"color:#000080;font-weight:bold;">typename</span>... T>
<span style=3D"color:#000080;font-weight:bold;">struct </span>tuple_like {
<span style=3D"color:#000080;font-weight:bold;">template </span><<sp=
an style=3D"color:#000080;font-weight:bold;">typename</span>... U>
tuple_like(U&& ... <span style=3D"color:#660e7a;font-weight:bol=
d;font-style:italic;">args</span>)
: items_(std::forward<U>(<span style=3D"color:#660e7a;fon=
t-weight:bold;font-style:italic;">args</span>)...) {}
<span style=3D"color:#000080;font-weight:bold;">template </span><std=
::size_t I>
<span style=3D"color:#000080;font-weight:bold;">decltype</span>(<span s=
tyle=3D"color:#000080;font-weight:bold;">auto</span>) get() <span style=3D"=
color:#000080;font-weight:bold;">const </span>{ <span style=3D"color:#00008=
0;font-weight:bold;">return </span>std::get<I>(items_); }
<span style=3D"color:#000080;font-weight:bold;">template </span><std=
::size_t I>
<span style=3D"color:#000080;font-weight:bold;">decltype</span>(<span s=
tyle=3D"color:#000080;font-weight:bold;">auto</span>) get() { <span style=
=3D"color:#000080;font-weight:bold;">return </span>std::get<I>(items_=
); }
<span style=3D"color:#000080;font-weight:bold;">private</span>:
std::tuple<T...> items_;
};
} <span style=3D"color:#808080;font-style:italic;">// close my namespace
</span><span style=3D"color:#808080;font-style:italic;">
</span><span style=3D"color:#000080;font-weight:bold;">namespace </span>std=
{
<span style=3D"color:#000080;font-weight:bold;">template </span><<span s=
tyle=3D"color:#000080;font-weight:bold;">typename</span>... T>
<span style=3D"color:#000080;font-weight:bold;">struct </span>tuple_size<=
;my::tuple_like<T...>>
: integral_constant<std::size_t, <span style=3D"color:#000080;fo=
nt-weight:bold;">sizeof</span>...(T)> {};
<span style=3D"color:#000080;font-weight:bold;">template </span><size_t =
I, <span style=3D"color:#000080;font-weight:bold;">typename</span>... T>
<span style=3D"color:#000080;font-weight:bold;">struct </span>tuple_element=
<I, my::tuple_like<T...>>
: tuple_element<I, tuple<T...>> {};
}
} <span style=3D"color:#808080;font-style:italic;">// close std namespace
</span><span style=3D"color:#808080;font-style:italic;">
</span><span style=3D"color:#000080;font-weight:bold;">namespace </span>my =
{ <span style=3D"color:#808080;font-style:italic;">// re-enter my namespace
</span><span style=3D"color:#808080;font-style:italic;">
</span><span style=3D"color:#808080;font-style:italic;">/* ...other declara=
tions... */
</span><span style=3D"color:#808080;font-style:italic;">
</span>}</pre></pre>
<pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=
=3D"arial, sans-serif">
</font></pre>
<pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;">
</pre>
<pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=
=3D"arial, sans-serif">Breaking out of my own namespace like this, adding s=
ome specialisations to namespace </font><font face=3D"courier new, monospac=
e">std</font><font face=3D"arial, sans-serif">, and then re-entering</font>=
</pre>
<pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=
=3D"arial, sans-serif">my own namespace is messy; it breaks the "flow" of a=
header file. For this reason, specialisations like this are often</font></=
pre>
<pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=
=3D"arial, sans-serif">tucked away at the bottom of a header, far away from=
where they (logically) belong, and where they can easily be</font></pre>
<pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=
=3D"arial, sans-serif">overlooked during refactoring. With functions like <=
/font><font face=3D"courier new, monospace">get()</font><font face=3D"arial=
, sans-serif"> and </font><font face=3D"courier new, monospace">swap()</fon=
t><font face=3D"arial, sans-serif">, this is mitigated by the use of unqual=
ified</font></pre>
<pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=
=3D"arial, sans-serif">calls and ADL, but for class specialisations like th=
ose required for structured bindings there is no alternative but to do</fon=
t></pre>
<pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=
=3D"arial, sans-serif">the namespace dance.</font></pre>
<pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=
=3D"arial, sans-serif">
</font></pre>
<pre style=3D"color: rgb(0, 0, 0);"><font size=3D"4" face=3D"ar=
ial, sans-serif">Proposal</font></pre>
<pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=
=3D"arial, sans-serif">
</font></pre>
<pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=
=3D"arial, sans-serif">What I'd like to suggest is to allow specialising ty=
pes in an unrelated namespace by fully-qualifying the name of the type</fon=
t></pre>
<pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=
=3D"arial, sans-serif">being specialised, as in:</font></pre>
<pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=
=3D"arial, sans-serif">
</font></pre>
<pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><pre style=
=3D"font-size: 9pt; font-family: Menlo;"><pre style=3D"font-family: Menlo; =
font-size: 9pt;"><span style=3D"color:#000080;font-weight:bold;">namespace =
</span>my {
<span style=3D"color:#000080;font-weight:bold;">struct </span>type { <span =
style=3D"color:#808080;font-style:italic;">/* ... */ </span>};
<span style=3D"color:#000080;font-weight:bold;">template </span><>
<span style=3D"color:#000080;font-weight:bold;">struct </span>::std::tuple_=
size<my::type>
<span style=3D"color:#808080;font-style:italic;">// ^^ here
</span>{
<span style=3D"color:#808080;font-style:italic;">/* ... */
</span>};
}</pre></pre></pre>
<pre style=3D"color: rgb(0, 0, 0);"><font size=3D"4" face=3D"ar=
ial, sans-serif">
</font></pre>
<pre style=3D"color: rgb(0, 0, 0);"><font size=3D"4" face=3D"ar=
ial, sans-serif">Impact on existing code</font></pre>
<pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=
=3D"arial, sans-serif">
</font></pre>
<pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=
=3D"arial, sans-serif">This syntax is, to the best of my knowledge, current=
ly illegal, so there should be no issues with existing code.</font></pre>
<pre style=3D"color: rgb(0, 0, 0); font-size: 9pt;"><font face=
=3D"arial, sans-serif">
</font></pre>
<pre style=3D"color: rgb(0, 0, 0);"><font size=3D"4" face=3D"ar=
ial, sans-serif">Quick Questions</font></pre>
<pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-s=
erif">
</font></pre>
<pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-s=
erif">Q: Should we be able to use this syntax to <i>define</i> types in an =
unrelated namespace too?</font></pre>
<pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-s=
erif">
</font></pre>
<pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-s=
erif"><font color=3D"#000000"><span style=3D"font-size: 12px;">A: No, that =
would lead to more of the sort of awkward spaghetti code we're trying to av=
oid. </span></font><span style=3D"color: rgb(34, 34, 34);">This should be s=
trictly for</span></font></pre>
<pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-s=
erif"><span style=3D"color: rgb(34, 34, 34);">class template specialisation=
s: the compiler must have seen a declaration of the base template beforehan=
d.</span></font></pre>
<pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-s=
erif"><span style=3D"color: rgb(34, 34, 34);">
</span></font></pre>
</div>
</div>
</div>
</blockquote>
<font face=3D"arial, sans-serif">I agree.</font><br>
<blockquote
cite=3D"mid:5bd1ff39-eb86-4d46-b75a-99cc80f8f114@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>
<div>
<pre style=3D"color: rgb(0, 0, 0);"><pre><font face=3D"arial, s=
ans-serif">Q: Inside the specialisation, are names from the enclosing names=
pace in scope?</font></pre><pre><font face=3D"arial, sans-serif">
</font></pre><pre><font face=3D"arial, sans-serif">A: Ideally, yes. I'd lik=
e to be able to have</font></pre><pre><font face=3D"arial, sans-serif">
</font></pre><pre><pre style=3D"font-size: 9pt; font-family: Menlo;"><span =
style=3D"color: rgb(0, 0, 128); font-weight: bold;">namespace </span>my {
<span style=3D"color: rgb(0, 0, 128); font-weight: bold;">template </span>&=
lt;>
<span style=3D"color: rgb(0, 0, 128); font-weight: bold;">struct </span>::s=
td::tuple_size<type>
<span style=3D"color: rgb(128, 128, 128); font-style: italic;">// ^^ he=
re
</span>{
<span style=3D"color: rgb(128, 128, 128); font-style: italic;">/* ... *=
/
</span>};
}</pre></pre><pre><font face=3D"arial, sans-serif">
</font></pre><pre><font face=3D"arial, sans-serif">as being equivalent to</=
font></pre><pre><font face=3D"arial, sans-serif">
</font></pre><pre><pre style=3D"font-family: Menlo; font-size: 9pt;">} <spa=
n style=3D"color:#808080;font-style:italic;">// exit my namespace
</span><span style=3D"color:#808080;font-style:italic;">
</span><span style=3D"color:#000080;font-weight:bold;">namespace </span>std=
{ <span style=3D"color:#808080;font-style:italic;">// enter namespace std
</span><span style=3D"color:#808080;font-style:italic;">
</span><span style=3D"color:#000080;font-weight:bold;">using namespace </sp=
an>my; <span style=3D"color:#808080;font-style:italic;">// bring my names i=
nto scope
</span><span style=3D"color:#808080;font-style:italic;">
</span><span style=3D"color:#000080;font-weight:bold;">template </span><=
>
<span style=3D"color:#000080;font-weight:bold;">struct </span>tuple_size<=
;type> { <span style=3D"color:#808080;font-style:italic;">/*... */ </spa=
n>};
} <span style=3D"color:#808080;font-style:italic;">// exit std namespace
</span><span style=3D"color:#808080;font-style:italic;">
</span><span style=3D"color:#000080;font-weight:bold;">namespace </span>my =
{ <span style=3D"color:#808080;font-style:italic;">// re-enter my namespace=
</span></pre></pre><pre><font face=3D"arial, sans-serif">
</font></pre><pre><font face=3D"arial, sans-serif">that is, names from both=
namespaces are available without qualification (except where required for =
disambiguation).</font></pre><pre><font face=3D"arial, sans-serif">However,=
if this isn't possible or creates parsing problems, then requiring types f=
rom the surrounding namespace to</font></pre><pre><font face=3D"arial, sans=
-serif">be qualified (i.e. as if the above </font><font face=3D"courier ne=
w, monospace">using namespace</font><font face=3D"arial, sans-serif"> decla=
ration wasn't present)</font></pre><pre><font face=3D"arial, sans-serif">do=
esn't seem to me that it would be too hard to learn or teach. It is exactly=
what we are required</font></pre><pre><font face=3D"arial, sans-serif">to =
do today.</font></pre><pre>
</pre></pre>
</div>
</div>
</div>
</blockquote>
For coherency as you are in your namespace it seems natural to be
able to use anything is in scope.<br>
<blockquote
cite=3D"mid:5bd1ff39-eb86-4d46-b75a-99cc80f8f114@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>
<div>
<pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-s=
erif"><span style=3D"color: rgb(34, 34, 34);">Q: Should we allow specialisi=
ng function templates with this syntax too?</span></font></pre>
<pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-s=
erif"><span style=3D"color: rgb(34, 34, 34);">
</span></font></pre>
<pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-s=
erif"><span style=3D"color: rgb(34, 34, 34);">A: No, for two reasons. First=
ly, the recommended way to implement function customisation points is to pr=
ovide
</span></font></pre>
<pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-s=
erif"><span style=3D"color: rgb(34, 34, 34);">an overload in one's own name=
space. Allowing this syntax for functions would encourage placing specialis=
ations</span></font></pre>
<pre style=3D"color: rgb(0, 0, 0);"><span style=3D"color: rgb(3=
4, 34, 34);"><font face=3D"arial, sans-serif">in namespace</font><font face=
=3D"courier new, monospace"> std</font><font face=3D"arial, sans-serif"> in=
stead. Secondly, the syntax</font></span></pre>
<pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-s=
erif"><span style=3D"color: rgb(34, 34, 34);">
</span></font></pre>
<pre style=3D"color: rgb(0, 0, 0);"><pre style=3D"font-family: =
Menlo; font-size: 9pt;"><span style=3D"color:#000080;font-weight:bold;">tem=
plate </span><>
my_type ::unrelated_ns::func<my_type>(<span style=3D"color:#000080;fo=
nt-weight:bold;">const </span>my_type& <span style=3D"color:#660e7a;fon=
t-weight:bold;font-style:italic;">arg</span>);</pre></pre>
<pre style=3D"color: rgb(0, 0, 0);">
</pre>
<pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-s=
erif">looks to the compiler (and to a human at a quick glance) like </font>=
<font face=3D"courier new, monospace">my_type::unrelated_ns::func</font><fo=
nt face=3D"arial, sans-serif">, i.e. whitespace is</font></pre>
<pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-s=
erif">ignored before the double colon. We could get around this by saying t=
hat such specialisations must use the</font></pre>
<pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-s=
erif">trailing-return syntax (because </font><font face=3D"courier new, mon=
ospace">auto::unrelated::func()</font><font face=3D"arial, sans-serif"> is =
never correct AFAIK), but adding</font></pre>
<pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-s=
erif">such a special case to parsing doesn't seem worth the benefit since, =
again, there is much less need to specialise</font></pre>
<pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-s=
erif">function templates in other namespaces compared with classes.</font><=
/pre>
<pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-s=
erif">
</font></pre>
</div>
</div>
</div>
</blockquote>
<font face=3D"arial, sans-serif">See [</font>N1295<font face=3D"arial,
sans-serif">] </font><font face=3D"arial, sans-serif"><font
face=3D"arial, sans-serif"></font></font><font face=3D"arial,
sans-serif"><font face=3D"arial, sans-serif">
<pre>Partial specialization of function templates</pre>
</font></font><font face=3D"arial, sans-serif"><font face=3D"arial,
sans-serif">
</font></font><font face=3D"arial, sans-serif"><a class=3D"moz-txt-li=
nk-freetext" href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/200=
1/n1295.asc">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2001/n1295.=
asc</a></font><br>
<blockquote
cite=3D"mid:5bd1ff39-eb86-4d46-b75a-99cc80f8f114@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>
<div>
<pre style=3D"color: rgb(0, 0, 0);">
</pre>
<pre style=3D"color: rgb(0, 0, 0);"><font size=3D"4" face=3D"ar=
ial, sans-serif">Summary</font></pre>
<pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-s=
erif">
</font></pre>
<pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-s=
erif">Allowing this small syntax change strictly for providing class templa=
te specialisations in unrelated namespaces will reduce</font></pre>
<pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-s=
erif">spaghetti code in headers/modules and make structured bindings suppor=
t easier and cleaner to implement.</font></pre>
<pre style=3D"color: rgb(0, 0, 0);"><font face=3D"arial, sans-s=
erif">We should allow it in C++20 :).</font></pre>
<pre style=3D"color: rgb(0, 0, 0);">
</pre>
</div>
</div>
</div>
</blockquote>
I don't know what where the reasons this old proposal was not
followed.<br>
<br>
I think it is worth trying it again.<br>
Vicente<br>
</body>
</html>
<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/52c31d25-c82f-09b3-e37b-c1e7e8e3ffc7%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/52c31d25-c82f-09b3-e37b-c1e7e8e3ffc7=
%40wanadoo.fr</a>.<br />
--------------7BEDFE81379B7325D0C80DA1--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Sat, 29 Apr 2017 15:48:48 -0700 (PDT)
Raw View
------=_Part_2153_680030326.1493506128524
Content-Type: multipart/alternative;
boundary="----=_Part_2154_305377256.1493506128524"
------=_Part_2154_305377256.1493506128524
Content-Type: text/plain; charset=UTF-8
>
> This was already proposed long time ago together with a another feature.
> You can take a look at [N1691] Explicit Namespaces
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1691.html
> <http://www.google.com/url?q=http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2004%2Fn1691.html&sa=D&sntz=1&usg=AFQjCNEQBzDxaI1jJrExDmTOitkDZrDRkw>
>
Isn't what Tristan has proposed standalone and self contained?
Why not make two separate proposals then?
I don't know what where the reasons this old proposal was not followed.
Do you mean the one on partial template specialization?
You could add an option to your proposal whether or not function template
specialization
(no matter whether explicit or implicit at some point) should be supported
using the trailling return type specification and let the committi give
input on that.
Jakob
--
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/641931cc-555f-4f84-8a91-3089842d621a%40isocpp.org.
------=_Part_2154_305377256.1493506128524
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"border-left: 1p=
x solid rgb(204, 204, 204); padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" te=
xt=3D"#000000">This was already proposed long time ago together with a anot=
her feature.<br>You can take a look at [N1691] Explicit Namespaces=C2=A0<br=
><a href=3D"http://www.google.com/url?q=3Dhttp%3A%2F%2Fwww.open-std.org%2Fj=
tc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2004%2Fn1691.html&sa=3DD&sntz=
=3D1&usg=3DAFQjCNEQBzDxaI1jJrExDmTOitkDZrDRkw" target=3D"_blank" rel=3D=
"nofollow" style=3D"cursor: pointer;">http://www.open-std.org/jtc1/<wbr>sc2=
2/wg21/docs/papers/2004/<wbr>n1691.html</a></div></blockquote><div>Isn'=
t what Tristan has proposed standalone and self contained?</div><div>Why no=
t make two separate proposals then?</div><div><br></div><div><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-le=
ft: 1px solid rgb(204, 204, 204); padding-left: 1ex;">I don't know what=
where the reasons this old proposal was not followed.</blockquote><div>=C2=
=A0</div><div>Do you mean the one on partial template specialization?</div>=
<div><br></div><div><br></div><div>You could add an option to your proposal=
whether or not function template specialization</div><div>(no matter wheth=
er explicit or implicit at some point) should be supported using the traill=
ing return type specification and let the committi give input on that.</div=
><div><br></div><div>Jakob</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/641931cc-555f-4f84-8a91-3089842d621a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/641931cc-555f-4f84-8a91-3089842d621a=
%40isocpp.org</a>.<br />
------=_Part_2154_305377256.1493506128524--
------=_Part_2153_680030326.1493506128524--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sun, 30 Apr 2017 01:11:29 +0200
Raw View
This is a multi-part message in MIME format.
--------------A0D788401D70B069FE29CB66
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 30/04/2017 =C3=A0 00:48, Jakob Riedle a =C3=A9crit :
>
> This was already proposed long time ago together with a another
> feature.
> You can take a look at [N1691] Explicit Namespaces
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1691.html
> <http://www.google.com/url?q=3Dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2=
Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2004%2Fn1691.html&sa=3DD&sntz=3D1&usg=3DAFQj=
CNEQBzDxaI1jJrExDmTOitkDZrDRkw>
>
> Isn't what Tristan has proposed standalone and self contained?
> Why not make two separate proposals then?
I want the Tristan's proposal and IMO this feature is independent from=20
explicit namespaces. N1691 mixed these two features.
>
>
> I don't know what where the reasons this old proposal was not
> followed.
>
> Do you mean the one on partial template specialization?
Sorry, I meant N1691, but neither of them have been followed. We don't=20
have any :(
>
>
> You could add an option to your proposal whether or not function=20
> template specialization
> (no matter whether explicit or implicit at some point) should be=20
> supported using the trailling return type specification and let the=20
> committi give input on that.
>
I don't need function template specializations even if I will be for=20
them. I need some kind of explicit namespaces and Tristan's proposal.
Vicente
--=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/ef98aa20-62dc-6f7b-07fa-5cadca7ecb9c%40wanadoo.f=
r.
--------------A0D788401D70B069FE29CB66
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 30/04/2017 =C3=A0 00:48, Jakob Riedle=
a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:641931cc-555f-4f84-8a91-3089842d621a@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid
rgb(204, 204, 204); padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">This was already
proposed long time ago together with a another feature.<br>
You can take a look at [N1691] Explicit Namespaces=C2=A0<br>
<a moz-do-not-send=3D"true"
href=3D"http://www.google.com/url?q=3Dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%=
2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2004%2Fn1691.html&sa=3DD&sntz=3D1&a=
mp;usg=3DAFQjCNEQBzDxaI1jJrExDmTOitkDZrDRkw"
target=3D"_blank" rel=3D"nofollow" style=3D"cursor: pointer;"=
>http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2004/<wbr>n1691.ht=
ml</a></div>
</blockquote>
<div>Isn't what Tristan has proposed standalone and self
contained?</div>
<div>Why not make two separate proposals then?</div>
</div>
</blockquote>
I want the Tristan's proposal and IMO this feature is independent
from explicit namespaces. N1691 mixed these two features.<br>
<blockquote
cite=3D"mid:641931cc-555f-4f84-8a91-3089842d621a@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">I don't know what where the reasons this
old proposal was not followed.</blockquote>
<div>=C2=A0</div>
<div>Do you mean the one on partial template specialization?</div>
</div>
</blockquote>
Sorry, I meant N1691, but neither of them have been followed. We
don't have any :(<br>
<blockquote
cite=3D"mid:641931cc-555f-4f84-8a91-3089842d621a@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<div><br>
</div>
<div>You could add an option to your proposal whether or not
function template specialization</div>
<div>(no matter whether explicit or implicit at some point)
should be supported using the trailling return type
specification and let the committi give input on that.</div>
<div><br>
</div>
</div>
</blockquote>
I don't need function template specializations even if I will be for
them. I need some kind of explicit namespaces and Tristan's
proposal.<br>
<br>
Vicente<br>
</body>
</html>
<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/ef98aa20-62dc-6f7b-07fa-5cadca7ecb9c%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ef98aa20-62dc-6f7b-07fa-5cadca7ecb9c=
%40wanadoo.fr</a>.<br />
--------------A0D788401D70B069FE29CB66--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Sun, 30 Apr 2017 08:30:51 -0700 (PDT)
Raw View
------=_Part_2892_1969324185.1493566251338
Content-Type: multipart/alternative;
boundary="----=_Part_2893_2024371517.1493566251339"
------=_Part_2893_2024371517.1493566251339
Content-Type: text/plain; charset=UTF-8
I certainly see your point Vicente.
I'm not sure whether explicit namespaces are the right spot to adjust the
standard.
For me personally, I did not have the problem of unintended ADL ever.
I might just not be part of the audience your speaking to that has serious
problems with how ADL works right now.
IMO you might rather start a new thread on this, since both topics are
certainly related but don't depend on each other.
This way, we can pave the way for template specializations in unrelated
namespaces.
Jakob
--
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/94dec1a4-ac4e-4af3-858e-23946dda745d%40isocpp.org.
------=_Part_2893_2024371517.1493566251339
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I certainly see your point Vicente.<div>I'm not sure w=
hether explicit namespaces are the right spot to adjust the standard.</div>=
<div>For me personally, I did not have the problem of unintended ADL ever.<=
/div><div>I might just not be part of the audience your speaking to that ha=
s serious problems with how ADL works right now.</div><div><br></div><div>I=
MO you might rather start a new thread on this, since both topics are certa=
inly related but don't depend on each other.</div><div>This way, we can=
pave the way for template specializations in unrelated namespaces.</div><d=
iv><br></div><div>Jakob</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/94dec1a4-ac4e-4af3-858e-23946dda745d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/94dec1a4-ac4e-4af3-858e-23946dda745d=
%40isocpp.org</a>.<br />
------=_Part_2893_2024371517.1493566251339--
------=_Part_2892_1969324185.1493566251338--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sun, 30 Apr 2017 19:13:01 +0200
Raw View
Le 30/04/2017 =C3=A0 17:30, Jakob Riedle a =C3=A9crit :
> I certainly see your point Vicente.
> I'm not sure whether explicit namespaces are the right spot to adjust=20
> the standard.
> For me personally, I did not have the problem of unintended ADL ever.
> I might just not be part of the audience your speaking to that has=20
> serious problems with how ADL works right now.
No problem. I'm happy for you that you don't have the problems.
> IMO you might rather start a new thread on this, since both topics are=20
> certainly related but don't depend on each other.
> This way, we can pave the way for template specializations in=20
> unrelated namespaces.
>
My intention was not to distract this thread. It was to signal that=20
something like that has already been proposed.
Vicente
--=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/c8b74a5b-9fd7-052f-291d-35348b7fc050%40wanadoo.f=
r.
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Mon, 1 May 2017 03:15:01 -0700 (PDT)
Raw View
------=_Part_1693_1356675252.1493633702023
Content-Type: multipart/alternative;
boundary="----=_Part_1694_695550187.1493633702023"
------=_Part_1694_695550187.1493633702023
Content-Type: text/plain; charset=UTF-8
>
> My intention was not to distract this thread. It was to signal that
> something like that has already been proposed.
>
Oh, sure, gotcha. Sorry for this imputation :)
Jakob
--
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/ac0f6501-7fa1-4093-a199-17d0ff1ebaba%40isocpp.org.
------=_Part_1694_695550187.1493633702023
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"border-left: 1p=
x solid rgb(204, 204, 204); padding-left: 1ex;">My intention was not to dis=
tract this thread. It was to signal that=C2=A0<br>something like that has a=
lready been proposed.<br></blockquote><div>Oh, sure, gotcha. Sorry for this=
imputation :)</div><div><br></div><div>Jakob=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" 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/ac0f6501-7fa1-4093-a199-17d0ff1ebaba%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ac0f6501-7fa1-4093-a199-17d0ff1ebaba=
%40isocpp.org</a>.<br />
------=_Part_1694_695550187.1493633702023--
------=_Part_1693_1356675252.1493633702023--
.