Topic: Providing machinery to allow template class
Author: jayrunting@gmail.com
Date: Sat, 15 Jul 2017 07:55:05 -0700 (PDT)
Raw View
------=_Part_169_909209880.1500130505670
Content-Type: multipart/alternative;
boundary="----=_Part_170_1806730639.1500130505671"
------=_Part_170_1806730639.1500130505671
Content-Type: text/plain; charset="UTF-8"
Hi, first time proposer here, if anyone finds something out of line by all
means let me correct myself.
The problem statement is easy: I want to use a library (std or otherwise)
and specialise a class within its namespace (a.k.a: std::hash), and I'd
like to do it all from my own namespace.
The core issue is that non-trivial amounts of code might be written, and
requiring all identifiers to be qualified gets tiresome quickly. It's
essentially a pragmatic blocker in the adoption of a more "typeclassy"
style of programming. From experience, this affects non-std usage in
general (hash is usually pretty terse!).
Specialising a template class inside a different name is currently
prohibited. This appears to be an arbitrary restriction, in that the
machinery required doesn't exist.
The practical issues are two: providing the compiler the signal that our
template specialisation is crossing over to another namespace, and
supplying the information required for the name-lookup(s). It is a trivial
number of characters to do both (parsing left as an exercise to the
reader), but the full ramifications escape me a little. Hence I'm floating
it here.
I have written a contrived code sample, and re-used the register keyword
because it is terse and it kind of fits (I'm "registering" my class to work
with a traits-class/typeclass). Actual syntax is flexible here. Again,
throw out suggestions for a different syntax.
namespace mythology
{
struct dragon {};
template <typename T>
struct brilliant_vector;
template <>
register struct std::hash<dragon>
{
// ...
};
// also partial specialization
template <typename T>
register struct ::std::hash<brilliant_vector<T>>
{
// ...
}
}
Let's assume we use the valuable register keyword, simply for brevity and
clarity.
1. The register keyword signifies to the compiler that we are entering a
"registering context". This is placed at the front so we can simplify
parsing.
2. Obviously prefixing namespaces in a class definition is illegal in
current C++. This would need to be alleviated for these registering
contexts.
3. Let's note that std::hash is fully qualified in the second example.
Whilst I can not think of any issues involving allowing unqualified lookup,
other than normal ones like ambiguity, this proposal could be restricted to
fully-qualified names.
4. These two specialisations place the specialised definition inside the
enclosing namespace of the found identifier. In the first example std::hash
is found through usual lookup, and such namespace std is chosen.
5. Finally, I'll point out there's no reason to forbid partial
specialisation.
After all of this, we can write definitions of (e.g.) std::hash whilst
inside our own namespace, and use all identifiers with regular name lookup.
We're not inside namespace std, we still need to qualify all names inside
the std namespace.
This was a bit of a stream of consciousness, so if you're still here, well
done you.
Cheers,
- Jonathan
--
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/e893cb32-5239-4363-9095-6ce76e310fc9%40isocpp.org.
------=_Part_170_1806730639.1500130505671
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi, first time proposer here, if anyone finds something ou=
t of line by all means let me correct myself.<div><br></div><div>The proble=
m statement is easy: I want to use a library (std or otherwise) and special=
ise a class within its namespace (a.k.a:=C2=A0<font face=3D"courier new, mo=
nospace"><span class=3D"styled-by-prettify" style=3D"background-color: rgb(=
250, 250, 250); color: rgb(0, 0, 0);">std</span><span class=3D"styled-by-pr=
ettify" style=3D"background-color: rgb(250, 250, 250); color: rgb(102, 102,=
0);">::</span><span class=3D"styled-by-prettify" style=3D"background-color=
: rgb(250, 250, 250); color: rgb(0, 0, 0);">hash</span></font>), and I'=
d like to do it all from my own namespace.</div><div><br></div><div>The cor=
e issue is that non-trivial amounts of code might be written, and requiring=
all identifiers to be qualified gets tiresome quickly. It's essentiall=
y a pragmatic blocker in the adoption of a more "typeclassy" styl=
e of programming. From experience, this affects non-std usage in general (h=
ash is usually pretty terse!).<br></div><div><br></div><div>Specialising a =
template class inside a different name is currently prohibited. This appear=
s to be an arbitrary restriction, in that the machinery required doesn'=
t exist.</div><div><br></div><div>The practical issues are two: providing t=
he compiler the signal that our template specialisation is crossing over to=
another namespace, and supplying the information required for the name-loo=
kup(s). It is a trivial number of characters to do both (parsing left as an=
exercise to the reader), but the full ramifications escape me a little. He=
nce I'm floating it here.<br></div><div><br></div><div>I have written a=
contrived code sample, and re-used the <font face=3D"courier new, monospac=
e">register</font> keyword because it is terse and it kind of fits (I'm=
"registering" my class to work with a traits-class/typeclass). A=
ctual syntax is flexible here. Again, throw out suggestions for a different=
syntax.</div><div><br></div><div><div class=3D"prettyprint" style=3D"backg=
round-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-s=
tyle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pret=
typrint"><div class=3D"subprettyprint"><font color=3D"#000088"><div class=
=3D"subprettyprint">namespace mythology</div><div class=3D"subprettyprint">=
{</div><div class=3D"subprettyprint"><span style=3D"white-space:pre"> </spa=
n>struct dragon {};</div><div class=3D"subprettyprint"><span style=3D"white=
-space:pre"> </span></div><div class=3D"subprettyprint"><span style=3D"whit=
e-space:pre"> </span>template <typename T></div><div class=3D"subpret=
typrint"><span style=3D"white-space:pre"> </span>struct brilliant_vector;</=
div><div class=3D"subprettyprint"><br></div><div class=3D"subprettyprint"><=
span style=3D"white-space:pre"> </span>template <></div><div class=3D=
"subprettyprint"><span style=3D"white-space:pre"> </span>register struct st=
d::hash<dragon></div><div class=3D"subprettyprint"><span style=3D"whi=
te-space:pre"> </span>{</div><div class=3D"subprettyprint"><span style=3D"w=
hite-space:pre"> </span>// ...</div><div class=3D"subprettyprint"><span st=
yle=3D"white-space:pre"> </span>};</div><div class=3D"subprettyprint"><br><=
span style=3D"white-space: pre;"> </span>// also partial specialization<br>=
</div></font><font color=3D"#000088"><div class=3D"subprettyprint"><span st=
yle=3D"white-space:pre"> </span>template <typename T></div><div class=
=3D"subprettyprint"><span style=3D"white-space:pre"> </span>register struct=
::std::hash<brilliant_vector<T>></div><div class=3D"subprettyp=
rint"><span style=3D"white-space:pre"> </span>{</div><div class=3D"subprett=
yprint"><span style=3D"white-space:pre"> </span>// ...</div><div class=3D"=
subprettyprint"><span style=3D"white-space:pre"> </span>}</div><div class=
=3D"subprettyprint">}</div></font></div></code></div><br><br></div><div>Let=
's assume we use the valuable register keyword, simply for brevity and =
clarity.</div><div><br></div><div><ol><li>The register keyword signifies to=
the compiler that we are entering a "registering context". This =
is placed at the front so we can simplify parsing.<br></li><li>Obviously pr=
efixing namespaces in a class definition is illegal in current C++. This wo=
uld need to be alleviated for these registering contexts.<br></li><li>Let&#=
39;s note that std::hash is fully qualified in the second example. Whilst I=
can not think of any issues involving allowing unqualified lookup, other t=
han normal ones like ambiguity, this proposal could be restricted to fully-=
qualified names.<br></li><li>These two specialisations place the specialise=
d definition inside the enclosing namespace of the found identifier. In the=
first example std::hash is found through usual lookup, and such namespace =
std is chosen.<br></li><li>Finally, I'll point out there's no reaso=
n to forbid partial specialisation.</li></ol>After all of this, we can writ=
e definitions of (e.g.) std::hash whilst inside our own namespace, and use =
all identifiers with regular name lookup. We're not inside namespace st=
d, we still need to qualify all names inside the std namespace.</div><div><=
br></div><div><br></div><div>This was a bit of a stream of consciousness, s=
o if you're still here, well done you.</div><div><br></div><div>Cheers,=
</div><div>=C2=A0- Jonathan</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/e893cb32-5239-4363-9095-6ce76e310fc9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e893cb32-5239-4363-9095-6ce76e310fc9=
%40isocpp.org</a>.<br />
------=_Part_170_1806730639.1500130505671--
------=_Part_169_909209880.1500130505670--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Sat, 15 Jul 2017 14:57:55 +0000
Raw View
--001a114682e6a9ab2905545c64de
Content-Type: text/plain; charset="UTF-8"
There's currently a paper on this, P0665, which I've presented and that has
been favorably received by the EWG, with some further comments on possibly
some restrictions as to what can be specialized in what namespaces; there's
going to be revisions of that paper, possibly getting looked at by Core in
Albuquerque.
On Sat, Jul 15, 2017 at 10:55 AM <jayrunting@gmail.com> wrote:
> Hi, first time proposer here, if anyone finds something out of line by all
> means let me correct myself.
>
> The problem statement is easy: I want to use a library (std or otherwise)
> and specialise a class within its namespace (a.k.a: std::hash), and I'd
> like to do it all from my own namespace.
>
> The core issue is that non-trivial amounts of code might be written, and
> requiring all identifiers to be qualified gets tiresome quickly. It's
> essentially a pragmatic blocker in the adoption of a more "typeclassy"
> style of programming. From experience, this affects non-std usage in
> general (hash is usually pretty terse!).
>
> Specialising a template class inside a different name is currently
> prohibited. This appears to be an arbitrary restriction, in that the
> machinery required doesn't exist.
>
> The practical issues are two: providing the compiler the signal that our
> template specialisation is crossing over to another namespace, and
> supplying the information required for the name-lookup(s). It is a trivial
> number of characters to do both (parsing left as an exercise to the
> reader), but the full ramifications escape me a little. Hence I'm floating
> it here.
>
> I have written a contrived code sample, and re-used the register keyword
> because it is terse and it kind of fits (I'm "registering" my class to work
> with a traits-class/typeclass). Actual syntax is flexible here. Again,
> throw out suggestions for a different syntax.
>
> namespace mythology
> {
> struct dragon {};
> template <typename T>
> struct brilliant_vector;
>
> template <>
> register struct std::hash<dragon>
> {
> // ...
> };
>
> // also partial specialization
> template <typename T>
> register struct ::std::hash<brilliant_vector<T>>
> {
> // ...
> }
> }
>
>
> Let's assume we use the valuable register keyword, simply for brevity and
> clarity.
>
>
> 1. The register keyword signifies to the compiler that we are entering
> a "registering context". This is placed at the front so we can simplify
> parsing.
> 2. Obviously prefixing namespaces in a class definition is illegal in
> current C++. This would need to be alleviated for these registering
> contexts.
> 3. Let's note that std::hash is fully qualified in the second example.
> Whilst I can not think of any issues involving allowing unqualified lookup,
> other than normal ones like ambiguity, this proposal could be restricted to
> fully-qualified names.
> 4. These two specialisations place the specialised definition inside
> the enclosing namespace of the found identifier. In the first example
> std::hash is found through usual lookup, and such namespace std is chosen.
> 5. Finally, I'll point out there's no reason to forbid partial
> specialisation.
>
> After all of this, we can write definitions of (e.g.) std::hash whilst
> inside our own namespace, and use all identifiers with regular name lookup.
> We're not inside namespace std, we still need to qualify all names inside
> the std namespace.
>
>
> This was a bit of a stream of consciousness, so if you're still here, well
> done you.
>
> Cheers,
> - Jonathan
>
> --
> 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/e893cb32-5239-4363-9095-6ce76e310fc9%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e893cb32-5239-4363-9095-6ce76e310fc9%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CAPCFJdShRnO1QRtzwta7QwdxoXN9T7_MyGrPWeC08%2BsQcXSiOQ%40mail.gmail.com.
--001a114682e6a9ab2905545c64de
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">There's currently a paper on this, P0665, which I'=
ve presented and that has been favorably received by the EWG, with some fur=
ther comments on possibly some restrictions as to what can be specialized i=
n what namespaces; there's going to be revisions of that paper, possibl=
y getting looked at by Core in Albuquerque.</div><br><div class=3D"gmail_qu=
ote"><div dir=3D"ltr">On Sat, Jul 15, 2017 at 10:55 AM <<a href=3D"mailt=
o:jayrunting@gmail.com">jayrunting@gmail.com</a>> wrote:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr">Hi, first time proposer here, if =
anyone finds something out of line by all means let me correct myself.<div>=
<br></div><div>The problem statement is easy: I want to use a library (std =
or otherwise) and specialise a class within its namespace (a.k.a:=C2=A0<fon=
t face=3D"courier new, monospace"><span class=3D"m_1658041047180521644style=
d-by-prettify" style=3D"background-color:rgb(250,250,250);color:rgb(0,0,0)"=
>std</span><span class=3D"m_1658041047180521644styled-by-prettify" style=3D=
"background-color:rgb(250,250,250);color:rgb(102,102,0)">::</span><span cla=
ss=3D"m_1658041047180521644styled-by-prettify" style=3D"background-color:rg=
b(250,250,250);color:rgb(0,0,0)">hash</span></font>), and I'd like to d=
o it all from my own namespace.</div><div><br></div><div>The core issue is =
that non-trivial amounts of code might be written, and requiring all identi=
fiers to be qualified gets tiresome quickly. It's essentially a pragmat=
ic blocker in the adoption of a more "typeclassy" style of progra=
mming. From experience, this affects non-std usage in general (hash is usua=
lly pretty terse!).<br></div><div><br></div><div>Specialising a template cl=
ass inside a different name is currently prohibited. This appears to be an =
arbitrary restriction, in that the machinery required doesn't exist.</d=
iv><div><br></div><div>The practical issues are two: providing the compiler=
the signal that our template specialisation is crossing over to another na=
mespace, and supplying the information required for the name-lookup(s). It =
is a trivial number of characters to do both (parsing left as an exercise t=
o the reader), but the full ramifications escape me a little. Hence I'm=
floating it here.<br></div><div><br></div><div>I have written a contrived =
code sample, and re-used the <font face=3D"courier new, monospace">register=
</font> keyword because it is terse and it kind of fits (I'm "regi=
stering" my class to work with a traits-class/typeclass). Actual synta=
x is flexible here. Again, throw out suggestions for a different syntax.</d=
iv><div><br></div><div><div class=3D"m_1658041047180521644prettyprint" styl=
e=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border=
-style:solid;border-width:1px;word-wrap:break-word"><code class=3D"m_165804=
1047180521644prettyprint"><div class=3D"m_1658041047180521644subprettyprint=
"><font color=3D"#000088"><div class=3D"m_1658041047180521644subprettyprint=
">namespace mythology</div><div class=3D"m_1658041047180521644subprettyprin=
t">{</div><div class=3D"m_1658041047180521644subprettyprint"><span style=3D=
"white-space:pre-wrap"> </span>struct dragon {};</div><div class=3D"m_16580=
41047180521644subprettyprint"><span style=3D"white-space:pre-wrap"> </span>=
</div><div class=3D"m_1658041047180521644subprettyprint"><span style=3D"whi=
te-space:pre-wrap"> </span>template <typename T></div><div class=3D"m=
_1658041047180521644subprettyprint"><span style=3D"white-space:pre-wrap"> <=
/span>struct brilliant_vector;</div><div class=3D"m_1658041047180521644subp=
rettyprint"><br></div><div class=3D"m_1658041047180521644subprettyprint"><s=
pan style=3D"white-space:pre-wrap"> </span>template <></div><div clas=
s=3D"m_1658041047180521644subprettyprint"><span style=3D"white-space:pre-wr=
ap"> </span>register struct std::hash<dragon></div><div class=3D"m_16=
58041047180521644subprettyprint"><span style=3D"white-space:pre-wrap"> </sp=
an>{</div><div class=3D"m_1658041047180521644subprettyprint"><span style=3D=
"white-space:pre-wrap"> </span>// ...</div><div class=3D"m_165804104718052=
1644subprettyprint"><span style=3D"white-space:pre-wrap"> </span>};</div><d=
iv class=3D"m_1658041047180521644subprettyprint"><br><span style=3D"white-s=
pace:pre-wrap"> </span>// also partial specialization<br></div></font><font=
color=3D"#000088"><div class=3D"m_1658041047180521644subprettyprint"><span=
style=3D"white-space:pre-wrap"> </span>template <typename T></div><d=
iv class=3D"m_1658041047180521644subprettyprint"><span style=3D"white-space=
:pre-wrap"> </span>register struct ::std::hash<brilliant_vector<T>=
></div><div class=3D"m_1658041047180521644subprettyprint"><span style=3D=
"white-space:pre-wrap"> </span>{</div><div class=3D"m_1658041047180521644su=
bprettyprint"><span style=3D"white-space:pre-wrap"> </span>// ...</div><di=
v class=3D"m_1658041047180521644subprettyprint"><span style=3D"white-space:=
pre-wrap"> </span>}</div><div class=3D"m_1658041047180521644subprettyprint"=
>}</div></font></div></code></div><br><br></div><div>Let's assume we us=
e the valuable register keyword, simply for brevity and clarity.</div><div>=
<br></div><div><ol><li>The register keyword signifies to the compiler that =
we are entering a "registering context". This is placed at the fr=
ont so we can simplify parsing.<br></li><li>Obviously prefixing namespaces =
in a class definition is illegal in current C++. This would need to be alle=
viated for these registering contexts.<br></li><li>Let's note that std:=
:hash is fully qualified in the second example. Whilst I can not think of a=
ny issues involving allowing unqualified lookup, other than normal ones lik=
e ambiguity, this proposal could be restricted to fully-qualified names.<br=
></li><li>These two specialisations place the specialised definition inside=
the enclosing namespace of the found identifier. In the first example std:=
:hash is found through usual lookup, and such namespace std is chosen.<br><=
/li><li>Finally, I'll point out there's no reason to forbid partial=
specialisation.</li></ol>After all of this, we can write definitions of (e=
..g.) std::hash whilst inside our own namespace, and use all identifiers wit=
h regular name lookup. We're not inside namespace std, we still need to=
qualify all names inside the std namespace.</div><div><br></div><div><br><=
/div><div>This was a bit of a stream of consciousness, so if you're sti=
ll here, well done you.</div><div><br></div><div>Cheers,</div><div>=C2=A0- =
Jonathan</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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/e893cb32-5239-4363-9095-6ce76e310fc9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e893cb32-5239-=
4363-9095-6ce76e310fc9%40isocpp.org</a>.<br>
</blockquote></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/CAPCFJdShRnO1QRtzwta7QwdxoXN9T7_MyGrP=
WeC08%2BsQcXSiOQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdShRnO1QR=
tzwta7QwdxoXN9T7_MyGrPWeC08%2BsQcXSiOQ%40mail.gmail.com</a>.<br />
--001a114682e6a9ab2905545c64de--
.