Topic: std::array::size() be made static?
Author: Anthony Hall <anthrond@gmail.com>
Date: Wed, 4 Jan 2017 23:28:31 -0800 (PST)
Raw View
------=_Part_3620_679546576.1483601311667
Content-Type: multipart/alternative;
boundary="----=_Part_3621_1351408504.1483601311668"
------=_Part_3621_1351408504.1483601311668
Content-Type: text/plain; charset=UTF-8
As a concrete example for the idea I'd like to float, suppose a class
template B derives publicly from std::array (whether or not this is a good
idea design-wise is another discussion):
template< typenameT, size_t N >
struct B : std::array<T, N>
{ };
Working with B, I ran into a surprise where it took me a while to figure
out why I couldn't use `std::tuple_size<B>` without a compiler error that
there was no such type: finally I realized the problem is that
`std::tuple_size<>` has no specialization for `class B`. I realize now,
from stackoverflow answers, (for example
http://stackoverflow.com/a/7980979/1286986) that the canonical solution is
to add my own specialization in the std namespace.
But before I became aware of that solution, I also made attempts to use the
expression `B::size()` in compile-time evaluated contexts. But I got
compiler errors that there was no such animal as `B::size()`. Of course,
this is because `B::size()` per the current standard is not static, as I
somehow assumed it would be.
*So my question: would it seem reasonable to others here to change
std::array::size() to be declared static *in future standards, as well as
constexpr and const as it now is? I realize that for most std containers,
size() must be non-static, or an instance member function, since most std
containers can have dynamic size. But I like the idea because, like the
example above, derived classes would benefit from having the equivalent of
a `std::tuple_size` operation automatically by inheritance, where
`std::tuple_size` itself does not since template specializations don't
extend to derived classes by default. And, by design std::array, has
static size, so why shouldn't size() be queryable at compile time even when
an instance object is not available? And even for instance objects, the
`b.size()` syntax should still work, as it does for calling class static
member functions through an instance.
I suppose another approach to make this automatic could be to change
std::tuple_size<std::array<>> to a partial specialization on a generic T,
with an enable_if on T to limit it to types derived from specializations of
std::array, but that seems more prone to having unintended side-effects,
and would be surprising for people who are now conversant in the convention
of manually specializing std::tuple_size for new classes.
-Andy
--
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/5d432263-8011-4d53-ab33-916270e7f6e5%40isocpp.org.
------=_Part_3621_1351408504.1483601311668
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">As a concrete example for the idea I'd like to float, =
suppose a class template B derives publicly from std::array (whether or not=
this is a good idea design-wise is another discussion):<div><br></div><div=
><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); =
border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; w=
ord-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyp=
rint"><span style=3D"color: #008;" class=3D"styled-by-prettify">template</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> typenameT</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">,</span><font color=
=3D"#000000"><span style=3D"color: #000;" class=3D"styled-by-prettify"> siz=
e_t N </span><span style=3D"color: #660;" class=3D"styled-by-prettify">>=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> B </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">array</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify"><</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> N</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">></span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">};</span></font></div></code></div><br>Wor=
king with B, I ran into a surprise where it took me a while to figure out w=
hy I couldn't use `std::tuple_size<B>` without a compiler error t=
hat there was no such type: finally I realized the problem is that `std::tu=
ple_size<>` has no specialization for `class B`. =C2=A0I realize now,=
from stackoverflow answers, (for example <a href=3D"http://stackoverflow.c=
om/a/7980979/1286986">http://stackoverflow.com/a/7980979/1286986</a>) that =
the canonical solution is to add my own specialization in the std namespace=
..</div><div><br></div><div>But before I became aware of that solution, I al=
so made attempts to use the expression `B::size()` in compile-time evaluate=
d contexts. =C2=A0But I got compiler errors that there was no such animal a=
s `B::size()`. =C2=A0Of course, this is because `B::size()` per the current=
standard is not static, as I somehow assumed it would be.</div><div><b><br=
></b></div><div><b>So my question: would it seem reasonable to others here =
to change std::array::size() to be declared static </b>in future standards,=
as well as constexpr and const as it now is? =C2=A0I realize that for most=
std containers, size() must be non-static, or an instance member function,=
since most std containers can have dynamic size. =C2=A0But I like the idea=
because, like the example above, derived classes would benefit from having=
the equivalent of a `std::tuple_size` operation automatically by inheritan=
ce, where `std::tuple_size` itself does not since template specializations =
don't extend to derived classes by default. =C2=A0And, by design std::a=
rray, has static size, so why shouldn't size() be queryable at compile =
time even when an instance object is not available? =C2=A0And even for inst=
ance objects, the `b.size()` syntax should still work, as it does for calli=
ng class static member functions through an instance.<br><br>I suppose anot=
her approach to make this automatic could be to change std::tuple_size<s=
td::array<>> to a partial specialization on a generic T, with an e=
nable_if on T to limit it to types derived from specializations of std::arr=
ay, but that seems more prone to having unintended side-effects, and would =
be surprising for people who are now conversant in the convention of manual=
ly specializing std::tuple_size for new classes.</div><div><br></div><div>-=
Andy</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/5d432263-8011-4d53-ab33-916270e7f6e5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5d432263-8011-4d53-ab33-916270e7f6e5=
%40isocpp.org</a>.<br />
------=_Part_3621_1351408504.1483601311668--
------=_Part_3620_679546576.1483601311667--
.
Author: "D. B." <db0451@gmail.com>
Date: Thu, 5 Jan 2017 08:41:30 +0000
Raw View
--001a114cc80c2b3af1054554de21
Content-Type: text/plain; charset=UTF-8
On Thu, Jan 5, 2017 at 7:28 AM, Anthony Hall <anthrond@gmail.com> wrote:
> (whether or not this is a good idea design-wise is another discussion)
>
I'm not sure it is. Whether it's a good idea design-wise correlates almost
directly with whether there's a good reason to alter the design ot the
language and make the size static, doesn't it? And IMO, it's not a good
idea design-wise.
And, by design std::array, has static size, so why shouldn't size() be
> queryable at compile time even when an instance object is not available?
>
Mildly convincing, although tuple_size seems close enough for me, and if
for some reason (that I cannot imagine) I did feel the need to inherit from
std::array, I'd have no real issue with reimplementing the size() method or
whatever my preferred method of exposing this info was, in terms of the
base class.
--
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/CACGiwhHbb6JNBMEJ9xYBmsVPzf-kxiWiNpkW93Q5nqmp4oc%3D%2Bg%40mail.gmail.com.
--001a114cc80c2b3af1054554de21
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jan 5, 2017 at 7:28 AM, Anthony Hall <span dir=3D"ltr"><<a href=3D"m=
ailto:anthrond@gmail.com" target=3D"_blank">anthrond@gmail.com</a>></spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">(whether or no=
t this is a good idea design-wise is another discussion)</div></blockquote>=
<div><br></div><div>I'm not sure it is. Whether it's a good idea de=
sign-wise correlates almost directly with whether there's a good reason=
to alter the design ot the language and make the size static, doesn't =
it? And IMO, it's not a good idea design-wise.<br></div><div>=C2=A0<br>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div>And, by design std::array, ha=
s static size, so why shouldn't size() be queryable at compile time eve=
n when an instance object is not available?</div></blockquote><div><br></di=
v><div>Mildly convincing, although tuple_size seems close enough for me, an=
d if for some reason (that I cannot imagine) I did feel the need to inherit=
from std::array, I'd have no real issue with reimplementing the size()=
method or whatever my preferred method of exposing this info was, in terms=
of the base class. <br></div></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhHbb6JNBMEJ9xYBmsVPzf-kxiWiNpkW=
93Q5nqmp4oc%3D%2Bg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHbb6JN=
BMEJ9xYBmsVPzf-kxiWiNpkW93Q5nqmp4oc%3D%2Bg%40mail.gmail.com</a>.<br />
--001a114cc80c2b3af1054554de21--
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 5 Jan 2017 09:52:36 -0500
Raw View
--94eb2c09c51e5ab3f405455a0d37
Content-Type: text/plain; charset=UTF-8
On Thu, Jan 5, 2017 at 2:28 AM, Anthony Hall <anthrond@gmail.com> wrote:
>
> *So my question: would it seem reasonable to others here to change
> std::array::size() to be declared static *in future standards, as well as
> constexpr and const as it now is?
>
boost::array always had a static size, iirc, and that long predated
std::array being in a standard. Knowing that, there may be rationale in the
standard proposal for why this was changed to not be static. I'm willing to
bet that this was at least discussed at the time, if anyone wanted to look
more deeply into it.
That said, I personally think it would have been better if the size
function were static for std::array, unless someone can provide convincing
rationale otherwise.
--
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/CANh8DEn6p4zZP18pr74zTs2jh7SbniYnoS2CTFdvcFnFe_Xc9A%40mail.gmail.com.
--94eb2c09c51e5ab3f405455a0d37
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jan 5, 2017 at 2:28 AM, Anthony Hall <span dir=3D"ltr"><<a href=3D"m=
ailto:anthrond@gmail.com" target=3D"_blank">anthrond@gmail.com</a>></spa=
n> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><b>So my ques=
tion: would it seem reasonable to others here to change std::array::size() =
to be declared static </b>in future standards, as well as constexpr and con=
st as it now is?<br></div></div></blockquote><div><br></div><div>boost::arr=
ay always had a static size, iirc, and that long predated std::array being =
in a standard. Knowing that, there may be rationale in the standard proposa=
l for why this was changed to not be static. I'm willing to bet that th=
is was at least discussed at the time, if anyone wanted to look more deeply=
into it.</div><div><br></div><div>That said, I personally think it would h=
ave been better if the size function were static for std::array, unless som=
eone can provide convincing rationale otherwise.</div></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/CANh8DEn6p4zZP18pr74zTs2jh7SbniYnoS2C=
TFdvcFnFe_Xc9A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEn6p4zZP18p=
r74zTs2jh7SbniYnoS2CTFdvcFnFe_Xc9A%40mail.gmail.com</a>.<br />
--94eb2c09c51e5ab3f405455a0d37--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 5 Jan 2017 18:10:04 +0100
Raw View
This is a multi-part message in MIME format.
--------------40F223ACBEF80162BFC83348
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 05/01/2017 =C3=A0 08:28, Anthony Hall a =C3=A9crit :
> As a concrete example for the idea I'd like to float, suppose a class=20
> template B derives publicly from std::array (whether or not this is a=20
> good idea design-wise is another discussion):
>
> |
> template<typenameT,size_t N >
> structB :std::array<T,N>
> {};
> |
>
> Working with B, I ran into a surprise where it took me a while to=20
> figure out why I couldn't use `std::tuple_size<B>` without a compiler=20
> error that there was no such type: finally I realized the problem is=20
> that `std::tuple_size<>` has no specialization for `class B`. I=20
> realize now, from stackoverflow answers, (for example=20
> http://stackoverflow.com/a/7980979/1286986) that the canonical=20
> solution is to add my own specialization in the std namespace.
>
There is an ongoing proposal about product types access that would give=20
you access to any product type
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0327r1.pdf
However, as for C++17 I believe your class wouldn't be considered as=20
supporting structure binding and as a consequence wouldn't be a product=20
type.
Nevertheless, I hope C++20 structure binding will support your class as=20
it is currently a C++17 aggregate.
> But before I became aware of that solution, I also made attempts to=20
> use the expression `B::size()` in compile-time evaluated contexts.=20
> But I got compiler errors that there was no such animal as=20
> `B::size()`. Of course, this is because `B::size()` per the current=20
> standard is not static, as I somehow assumed it would be.
> *
> *
> *So my question: would it seem reasonable to others here to change=20
> std::array::size() to be declared static *in future standards, as well=20
> as constexpr and const as it now is?
I believe this shouldn't be controversial with a concrete proposal (I=20
wouldn't expect this non-backward compatible change to break too much=20
code).
I don't see this change in the future standard C++17.
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/d90c6a51-a8f8-23d8-8a65-956caebc6872%40wanadoo.f=
r.
--------------40F223ACBEF80162BFC83348
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 05/01/2017 =C3=A0 08:28, Anthony Hall=
a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:5d432263-8011-4d53-ab33-916270e7f6e5@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">As a concrete example for the idea I'd like to
float, suppose a class template B derives publicly from
std::array (whether or not this is a good idea design-wise is
another discussion):
<div><br>
</div>
<div>
<div class=3D"prettyprint" style=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"prettyprint">
<div class=3D"subprettyprint"><span style=3D"color: #008;"
class=3D"styled-by-prettify">template</span><span
style=3D"color: #660;" class=3D"styled-by-prettify"><<=
/span><span
style=3D"color: #000;" class=3D"styled-by-prettify">
typenameT</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">,</span><font
color=3D"#000000"><span style=3D"color: #000;"
class=3D"styled-by-prettify"> size_t N </span><span
style=3D"color: #660;" class=3D"styled-by-prettify">>=
;</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>
</span><span style=3D"color: #008;"
class=3D"styled-by-prettify">struct</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> B =
</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">:</=
span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> st=
d</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">::<=
/span><span
style=3D"color: #000;" class=3D"styled-by-prettify">arr=
ay</span><span
style=3D"color: #660;" class=3D"styled-by-prettify"><=
;</span><span
style=3D"color: #000;" class=3D"styled-by-prettify">T</=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify">,</=
span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> N<=
/span><span
style=3D"color: #660;" class=3D"styled-by-prettify">>=
;</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>
</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">{</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify">};<=
/span></font></div>
</code></div>
<br>
Working with B, I ran into a surprise where it took me a while
to figure out why I couldn't use `std::tuple_size<B>`
without a compiler error that there was no such type: finally
I realized the problem is that `std::tuple_size<>` has
no specialization for `class B`. =C2=A0I realize now, from
stackoverflow answers, (for example <a moz-do-not-send=3D"true"
href=3D"http://stackoverflow.com/a/7980979/1286986">http://stac=
koverflow.com/a/7980979/1286986</a>)
that the canonical solution is to add my own specialization in
the std namespace.</div>
<div><br>
</div>
</div>
</blockquote>
There is an ongoing proposal about product types access that would
give you access to any product type<br>
<br>
<a class=3D"moz-txt-link-freetext" href=3D"http://www.open-std.org/jtc1=
/sc22/wg21/docs/papers/2016/p0327r1.pdf">http://www.open-std.org/jtc1/sc22/=
wg21/docs/papers/2016/p0327r1.pdf</a><br>
<br>
However, as for C++17 I believe your class wouldn't be considered as
supporting structure binding and as a consequence wouldn't be a
product type.<br>
Nevertheless, I hope C++20 structure binding will support your class
as it is currently a C++17 aggregate.<br>
<br>
<blockquote
cite=3D"mid:5d432263-8011-4d53-ab33-916270e7f6e5@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>But before I became aware of that solution, I also made
attempts to use the expression `B::size()` in compile-time
evaluated contexts. =C2=A0But I got compiler errors that there wa=
s
no such animal as `B::size()`. =C2=A0Of course, this is because
`B::size()` per the current standard is not static, as I
somehow assumed it would be.</div>
<div><b><br>
</b></div>
<div><b>So my question: would it seem reasonable to others here
to change std::array::size() to be declared static </b>in
future standards, as well as constexpr and const as it now
is?=C2=A0 <br>
</div>
</div>
</blockquote>
I believe this shouldn't be controversial with a concrete proposal
(I wouldn't expect this non-backward compatible change to break too
much code). <br>
I don't see this change in the future standard C++17.<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/d90c6a51-a8f8-23d8-8a65-956caebc6872%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d90c6a51-a8f8-23d8-8a65-956caebc6872=
%40wanadoo.fr</a>.<br />
--------------40F223ACBEF80162BFC83348--
.