------=_Part_3140_12630413.1373142379068
Content-Type: text/plain; charset=ISO-8859-1

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) == 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.

An obvious problem with that approach is integer overflowing, but it can be
easily fixed the same way it's fixed for integer literals:

constexpr foo::bar operator "" _foo(uint8_t); // so, only values in range
of 0..255 are allowed, that's why this:
auto baz = 256_foo; // gives `error: integer constant is too large for its
type`

This also gives automatic checking of parameter range for `operator""`s as
a nice side effects. Thoughts?

PS If there is some rationale for only allowing the biggest integer type in
`operator""`, I'd be really glad to be pointed to it - I looked at the UDL
proposal, but I failed to find it, and I cannot think of any right now.

--

---
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_3140_12630413.1373142379068
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 `u=
nsigned long long` on both Clang and GCC on Linux (despite the fact that `s=
izeof(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 requi=
red 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 argument=
s of any integral types.</div><div><br></div><div>An obvious problem with t=
hat approach is integer overflowing, but it can be easily fixed the same wa=
y it's fixed for integer literals:</div><div><br></div><div class=3D"pretty=
print" style=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb=
(187, 187, 187); word-wrap: break-word;"><code class=3D"prettyprint"><div c=
lass=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">constexpr</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> foo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">bar </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">operator</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #080;" class=3D"styled-by-prettify">""</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> _foo</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">uint8_t</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pr=
ettify">// so, only values in range of 0..255 are allowed, that's why this:=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> baz </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066=
;" class=3D"styled-by-prettify">256</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">_foo</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>// gives `error: integer constant is too large for its type`</span></div><=
/code></div><div><br></div><div>This also gives automatic checking of param=
eter range for `operator""`s as a nice side effects. Thoughts?</div><div><b=
r></div><div>PS If there is some rationale for only allowing the biggest in=
teger type in `operator""`, I'd be really glad to be pointed to it - I look=
ed at the UDL proposal, but I failed to find it, and I cannot think of any =
right now.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_3140_12630413.1373142379068--

.

------=_Part_7_21762004.1373141264677
Content-Type: text/plain; charset=ISO-8859-1

Today I came across a really silly problem - you cannot take `uint64_t` as
an argument of a user defined operator, because it's commonly a typedef for
`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
hope we all agree it's a silly situation.

So, I would like to propose to allow `operator""` use any integral type as
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,
like here:

constexpr uint64_t operator""_foo(uint8_t); // limit X in X_foo to range of
0..255
auto bar = 256_foo; // error: integer constant is too large for its type

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").

--

---
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_7_21762004.1373141264677
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Today I came across a really silly problem - you cannot take `uint64_t` as =
an argument of a user defined operator, because it's commonly a typedef for=
 `unsigned long`, not `unsigned long long` - even though they are both 64 b=
it on most sane ABIs, you cannot use `uint64_t` as type of `operator""`. I =
hope we all agree it's a silly situation.<div><br></div><div>So, I would li=
ke to propose to allow `operator""` use any integral type as its argument t=
ype.</div><div><br></div><div>There obviously could be a problem of the par=
ameter being bigger than `numeric_limits&lt;type&gt;::max()`, which can be =
solved by issuing an error, like here:</div><div><br></div><div class=3D"pr=
ettyprint" style=3D"background-color: rgb(250, 250, 250); border: 1px solid=
 rgb(187, 187, 187); word-wrap: break-word;"><code class=3D"prettyprint"><d=
iv class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by=
-prettify">constexpr</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> uint64_t </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">operator</span><span style=3D"color: #080;" class=3D"styled-by-pr=
ettify">""</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
_foo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">uint8_t</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #800;" class=3D"styled-by-prettify">// limit X in X_foo to range of 0..=
255</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> bar </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
066;" class=3D"styled-by-prettify">256</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">_foo</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pret=
tify">// error: integer constant is too large for its type</span></div></co=
de></div><div><br></div><div>And we'd also get free limit checking as a nic=
e side effect. Thoughts?</div><div><br></div><div>PS If the fact you can on=
ly use `unsigned long long` has some deeper reasoning I fail to see, I woul=
d welcome any explanation for it, but, as I said, I fail to see any benefit=
s of disallowing integral types other than `unsigned long long` (or "the bi=
ggest integral type available").</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_7_21762004.1373141264677--

.