Topic: Allowing any integral type as an argument for
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 7 Jul 2013 00:02:04 +0300
Raw View
--001a11c2c0eca340bc04e0de1fd0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 6 July 2013 23:26, Micha=C5=82 Dominiak <griwes@griwes.info> wrote:
> Today I came across a very silly issue: you cannot do `uint64_t
> operator""_foo(uint64_t)`, because `uint64_t` is a typedef for `unsigned
> long`, not `unsigned long long` on both Clang and GCC on Linux (despite t=
he
> fact that `sizeof(unsigned long) =3D=3D sizeof(unsigned long long)`). You=
have
> to type the long type name, just because the typedef isn't for the exact
> type required by the standard. I hope we all agree this is a silly
> situation.
>
> So, I'd like to propose allowing `operator""`s to take arguments of any
> integral types.
>
It's not supposed to take any integral types. The operator takes an
unsigned type because any negation
happens outside it. Since we already have such a restriction for the type a
literal operator accepts, it's
not a far stretch to have a further limitation. I wouldn't mind it
accepting any unsigned integral type,
but I don't see it a big deal that you have to have a certain signature for
a literal operator.
Not allowing multiple kinds of integral types as literal operator
parameters also avoid having
to deal with overload resolution for the literal operators, and not
allowing narrow types avoids
having to deal with narrowing conversions.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c2c0eca340bc04e0de1fd0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 6 July 2013 23:26, Micha=C5=82 Dominiak <span dir=3D"ltr"><<a=
href=3D"mailto:griwes@griwes.info" target=3D"_blank">griwes@griwes.info</a=
>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Today I came across a very silly issue: you =
cannot do `uint64_t operator""_foo(uint64_t)`, because `uint64_t`=
is a typedef for `unsigned long`, not `unsigned long long` on both Clang a=
nd GCC on Linux (despite the fact that `sizeof(unsigned long) =3D=3D sizeof=
(unsigned long long)`). You have to type the long type name, just because t=
he typedef isn't for the exact type required by the standard. I hope we=
all agree this is a silly situation.<div>
<br></div><div>So, I'd like to propose allowing `operator""`s=
to take arguments of any integral types.</div></blockquote><div><br></div>=
<div>It's not supposed to take any integral types. The operator takes a=
n unsigned type because any negation<br>
</div><div>happens outside it. Since we already have such a restriction for=
the type a literal operator accepts, it's<br>not a far stretch to have=
a further limitation. I wouldn't mind it accepting any unsigned integr=
al type,<br>
but I don't see it a big deal that you have to have a certain signature=
for a literal operator.<br><br></div><div>Not allowing multiple kinds of i=
ntegral types as literal operator parameters also avoid having<br></div>
<div>to deal with overload resolution for the literal operators, and not al=
lowing narrow types avoids<br>having to deal with narrowing conversions.<br=
></div></div></div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--001a11c2c0eca340bc04e0de1fd0--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Sat, 6 Jul 2013 14:15:48 -0700 (PDT)
Raw View
------=_Part_3275_1565986.1373145348862
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, 6 July 2013 23:02:04 UTC+2, Ville Voutilainen wrote:
>
>
>
>
> On 6 July 2013 23:26, Micha=C5=82 Dominiak <gri...@griwes.info <javascrip=
t:>>wrote:
>
>> Today I came across a very silly issue: you cannot do `uint64_t=20
>> operator""_foo(uint64_t)`, because `uint64_t` is a typedef for `unsigned=
=20
>> long`, not `unsigned long long` on both Clang and GCC on Linux (despite =
the=20
>> fact that `sizeof(unsigned long) =3D=3D sizeof(unsigned long long)`). Yo=
u have=20
>> to type the long type name, just because the typedef isn't for the exact=
=20
>> type required by the standard. I hope we all agree this is a silly=20
>> situation.
>>
>> So, I'd like to propose allowing `operator""`s to take arguments of any=
=20
>> integral types.
>>
>
> It's not supposed to take any integral types. The operator takes an=20
> unsigned type because any negation
> happens outside it. Since we already have such a restriction for the type=
=20
> a literal operator accepts, it's
> not a far stretch to have a further limitation. I wouldn't mind it=20
> accepting any unsigned integral type,
> but I don't see it a big deal that you have to have a certain signature=
=20
> for a literal operator.
>
Ok, s/any/any unsigned/.=20
=20
> Not allowing multiple kinds of integral types as literal operator=20
> parameters also avoid having
> to deal with overload resolution for the literal operators, and not=20
> allowing narrow types avoids
> having to deal with narrowing conversions.
>
=20
No-one says allowing any unsigned argument type would allow overloading (I=
=20
think it would be a counter-feature, really). And since you know all the=20
values passed to the operator at compile time, no narrowing would ever=20
happen - just slap the user with an error about the value being to big for=
=20
given type.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_3275_1565986.1373145348862
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Saturday, 6 July 2013 23:02:04 UTC+2, Ville Voutilainen wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div><br><=
br><div class=3D"gmail_quote">On 6 July 2013 23:26, Micha=C5=82 Dominiak <s=
pan dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"rcRsle36NrQJ">gri...@griwes.info</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Today I came across a very silly issue: you =
cannot do `uint64_t operator""_foo(uint64_t)`, because `uint64_t` is a type=
def for `unsigned long`, not `unsigned long long` on both Clang and GCC on =
Linux (despite the fact that `sizeof(unsigned long) =3D=3D sizeof(unsigned =
long long)`). You have to type the long type name, just because the typedef=
isn't for the exact type required by the standard. I hope we all agree thi=
s is a silly situation.<div>
<br></div><div>So, I'd like to propose allowing `operator""`s to take argum=
ents of any integral types.</div></blockquote><div><br></div><div>It's not =
supposed to take any integral types. The operator takes an unsigned type be=
cause any negation<br>
</div><div>happens outside it. Since we already have such a restriction for=
the type a literal operator accepts, it's<br>not a far stretch to have a f=
urther limitation. I wouldn't mind it accepting any unsigned integral type,=
<br>
but I don't see it a big deal that you have to have a certain signature for=
a literal operator.<br></div></div></div></div></blockquote><div><br></div=
><div>Ok, s/any/any unsigned/. </div><div> </div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quot=
e"><div></div><div>Not allowing multiple kinds of integral types as literal=
operator parameters also avoid having<br></div>
<div>to deal with overload resolution for the literal operators, and not al=
lowing narrow types avoids<br>having to deal with narrowing conversions.<br=
></div></div></div></div></blockquote><div> <br></div><div>No-one says=
allowing any unsigned argument type would allow overloading (I think it wo=
uld be a counter-feature, really). And since you know all the values passed=
to the operator at compile time, no narrowing would ever happen - just sla=
p the user with an error about the value being to big for given type.</div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_3275_1565986.1373145348862--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 7 Jul 2013 00:17:35 +0300
Raw View
--047d7b6dcf5214ebb504e0de571a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 7 July 2013 00:15, Micha=C5=82 Dominiak <griwes@griwes.info> wrote:
>
> It's not supposed to take any integral types. The operator takes an
>> unsigned type because any negation
>> happens outside it. Since we already have such a restriction for the typ=
e
>> a literal operator accepts, it's
>> not a far stretch to have a further limitation. I wouldn't mind it
>> accepting any unsigned integral type,
>> but I don't see it a big deal that you have to have a certain signature
>> for a literal operator.
>>
>
> Ok, s/any/any unsigned/.
>
>
>> Not allowing multiple kinds of integral types as literal operator
>> parameters also avoid having
>> to deal with overload resolution for the literal operators, and not
>> allowing narrow types avoids
>> having to deal with narrowing conversions.
>>
>
> No-one says allowing any unsigned argument type would allow overloading (=
I
> think it would be a counter-feature, really). And since you know all the
> values passed to the operator at compile time, no narrowing would ever
> happen - just slap the user with an error about the value being to big fo=
r
> given type.
>
>
>
>
Ok, so any unsigned type, no overloading with multiple integral types, and
any narrowing is ill-formed. With
that recipe, I wouldn't mind seeing a proposal about this. I'm not going to
write one myself. I may be able to
present one if necessary.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--047d7b6dcf5214ebb504e0de571a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 7 July 2013 00:15, Micha=C5=82 Dominiak <span dir=3D"ltr"><<a=
href=3D"mailto:griwes@griwes.info" target=3D"_blank">griwes@griwes.info</a=
>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><div class=3D"im"><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>It's not supposed=
to take any integral types. The operator takes an unsigned type because an=
y negation<br>
</div><div>happens outside it. Since we already have such a restriction for=
the type a literal operator accepts, it's<br>not a far stretch to have=
a further limitation. I wouldn't mind it accepting any unsigned integr=
al type,<br>
but I don't see it a big deal that you have to have a certain signature=
for a literal operator.<br></div></div></div></div></blockquote><div><br><=
/div></div><div>Ok, s/any/any unsigned/.=C2=A0</div><div class=3D"im"><div>=
=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D=
"gmail_quote"><div></div><div>Not allowing multiple kinds of integral types=
as literal operator parameters also avoid having<br>
</div>
<div>to deal with overload resolution for the literal operators, and not al=
lowing narrow types avoids<br>having to deal with narrowing conversions.<br=
></div></div></div></div></blockquote><div>=C2=A0<br></div></div><div>No-on=
e says allowing any unsigned argument type would allow overloading (I think=
it would be a counter-feature, really). And since you know all the values =
passed to the operator at compile time, no narrowing would ever happen - ju=
st slap the user with an error about the value being to big for given type.=
</div>
<div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
<br><br></div></div></blockquote><div><br></div><div>Ok, so any unsigned ty=
pe, no overloading with multiple integral types, and any narrowing is ill-f=
ormed. With<br></div><div>that recipe, I wouldn't mind seeing a proposa=
l about this. I'm not going to write one myself. I may be able to<br>
present one if necessary. <br></div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--047d7b6dcf5214ebb504e0de571a--
.
Author: jalobado@gmail.com
Date: Mon, 8 Jul 2013 04:35:38 -0700 (PDT)
Raw View
------=_Part_258_11292810.1373283338910
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, July 6, 2013 10:26:19 PM UTC+2, Micha=C5=82 Dominiak wrote:
>
> Today I came across a very silly issue: you cannot do `uint64_t=20
> operator""_foo(uint64_t)`, because `uint64_t` is a typedef for `unsigned=
=20
> long`, not `unsigned long long` on both Clang and GCC on Linux (despite t=
he=20
> fact that `sizeof(unsigned long) =3D=3D sizeof(unsigned long long)`). You=
have=20
> to type the long type name, just because the typedef isn't for the exact=
=20
> type required by the standard. I hope we all agree this is a silly=20
> situation.
I wasn't aware the standard required uint64_t to be typedef'ed to unsigned=
=20
long long int. I wasn't even aware the standard required long long to be=20
64-bit in the first place. Last time I checked long long had to be at least=
=20
64-bit but could be anything bigger. E.g. 128-bit would be OK. Can you=20
quote the chapter where the standard required uint64_t to be a typedef to=
=20
unsigned long long?
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_258_11292810.1373283338910
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, July 6, 2013 10:26:19 PM UTC+2, Micha=C5=82 Dominiak wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">Today I came across a very silly =
issue: you cannot do `uint64_t operator""_foo(uint64_t)`, because `uint64_t=
` is a typedef for `unsigned long`, not `unsigned long long` on both Clang =
and GCC on Linux (despite the fact that `sizeof(unsigned long) =3D=3D sizeo=
f(unsigned long long)`). You have to type the long type name, just because =
the typedef isn't for the exact type required by the standard. I hope we al=
l agree this is a silly situation.</blockquote><div><br></div><div>I wasn't=
aware the standard required uint64_t to be typedef'ed to unsigned long lon=
g int. I wasn't even aware the standard required long long to be 64-bit in =
the first place. Last time I checked long long had to be at least 64-bit bu=
t could be anything bigger. E.g. 128-bit would be OK. Can you quote the cha=
pter where the standard required uint64_t to be a typedef to unsigned long =
long?</div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_258_11292810.1373283338910--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 8 Jul 2013 20:23:02 +0300
Raw View
--047d7bdc9396f4c6fe04e1034bc4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 8 July 2013 14:35, <jalobado@gmail.com> wrote:
> On Saturday, July 6, 2013 10:26:19 PM UTC+2, Micha=C5=82 Dominiak wrote:
>>
>> Today I came across a very silly issue: you cannot do `uint64_t
>> operator""_foo(uint64_t)`, because `uint64_t` is a typedef for `unsigned
>> long`, not `unsigned long long` on both Clang and GCC on Linux (despite =
the
>> fact that `sizeof(unsigned long) =3D=3D sizeof(unsigned long long)`). Yo=
u have
>> to type the long type name, just because the typedef isn't for the exact
>> type required by the standard. I hope we all agree this is a silly
>> situation.
>
>
> I wasn't aware the standard required uint64_t to be typedef'ed to unsigne=
d
> long long int. I wasn't even aware the standard
>
It's not required to be unsigned long long.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--047d7bdc9396f4c6fe04e1034bc4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 8 July 2013 14:35, <span dir=3D"ltr"><<a href=3D"mailto:jalo=
bado@gmail.com" target=3D"_blank">jalobado@gmail.com</a>></span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Saturday, July 6, 2013 10:26:19 PM UTC+2, Micha=C5=82 =
Dominiak wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Today I came across =
a very silly issue: you cannot do `uint64_t operator""_foo(uint64=
_t)`, because `uint64_t` is a typedef for `unsigned long`, not `unsigned lo=
ng long` on both Clang and GCC on Linux (despite the fact that `sizeof(unsi=
gned long) =3D=3D sizeof(unsigned long long)`). You have to type the long t=
ype name, just because the typedef isn't for the exact type required by=
the standard. I hope we all agree this is a silly situation.</blockquote>
<div><br></div></div><div>I wasn't aware the standard required uint64_t=
to be typedef'ed to unsigned long long int. I wasn't even aware th=
e standard </div></blockquote><div><br></div><div>It's not required to =
be unsigned long long.<br>
<br></div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--047d7bdc9396f4c6fe04e1034bc4--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Mon, 8 Jul 2013 19:37:35 +0200
Raw View
2013/7/6 Micha=C5=82 Dominiak <griwes@griwes.info>:
> Today I came across a really silly problem - you cannot take `uint64_t` a=
s
> an argument of a user defined operator, because it's commonly a typedef f=
or
> `unsigned long`, not `unsigned long long` - even though they are both 64 =
bit
> on most sane ABIs, you cannot use `uint64_t` as type of `operator""`. I h=
ope
> we all agree it's a silly situation.
>
> So, I would like to propose to allow `operator""` use any integral type a=
s
> its argument type.
>
> There obviously could be a problem of the parameter being bigger than
> `numeric_limits<type>::max()`, which can be solved by issuing an error, l=
ike
> here:
>
> constexpr uint64_t operator""_foo(uint8_t); // limit X in X_foo to range =
of
> 0..255
> auto bar =3D 256_foo; // error: integer constant is too large for its typ=
e
>
> And we'd also get free limit checking as a nice side effect. Thoughts?
>
> PS If the fact you can only use `unsigned long long` has some deeper
> reasoning I fail to see, I would welcome any explanation for it, but, as =
I
> said, I fail to see any benefits of disallowing integral types other than
> `unsigned long long` (or "the biggest integral type available").
Presumably there is some overlap with the existing core language issue
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1266
- Daniel
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Mon, 8 Jul 2013 11:08:10 -0700 (PDT)
Raw View
------=_Part_9_11002636.1373306890412
Content-Type: text/plain; charset=ISO-8859-1
Ok, that's interesting. I'll probably try to write a sane proposal for
fixing the original problem, I'll include a sample solution for the issue
there.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_9_11002636.1373306890412
Content-Type: text/html; charset=ISO-8859-1
Ok, that's interesting. I'll probably try to write a sane proposal for fixing the original problem, I'll include a sample solution for the issue there.
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
<br />
<br />
------=_Part_9_11002636.1373306890412--
.