Topic: explicit underlying type conversion used in
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 26 Apr 2017 22:16:33 +0200
Raw View
This is a multi-part message in MIME format.
--------------B008C2494AE2E56271C9CE50
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 26/04/2017 =C3=A0 21:58, Vicente J. Botet Escriba a =C3=A9crit :
>
> Hi,
>
>
> we have that instances of types with an explicit conversion to bool=20
> can be used in if statements, with logical operators &&, ||, and ! and=20
> with the ?: operator.
>
>
> When we have strong type wrapping integers, we need to provide access=20
> to the underlying type and very often it is provided using an explicit=20
> conversion.
>
> However when we use a strong type in a switch we must use the access=20
> function or cast it to the integer, as in
>
> switch (st.value()) {
>
> ...
>
> or
>
> switch (int(st)) {
>
> ...
>
> or
>
> switch (underlying(st)) {
>
> ...
>
> where underlying is a function that do the cast to the underlying type.
>
> I was wondering if we can not extend the switch statement. It could=20
> accept any type convertible to an integral type (a type that can be in=20
> a switch condition). If more than one of these conversion is possible=20
> then the program will not be well formed.
>
> switch (st) {
>
> ...
>
>
> This could be useful where you have some generic code expecting an=20
> Integral type.
>
> template <class Integral>
> void f(Integral i)
> {
>
> switch (i) {
>
> ...
> }
>
> This code will not compile if we pass it a strong integer type=20
> wrapping an int. We would need to define a underlying function that=20
> works for enums, int and strong integer types e.g.
>
> template <class Integral>
> void f(Integral i)
> {
>
> switch (underlying(i)) {
>
> ...
> }
>
> I'm expecting that we will have more and more strong types, as e.g.=20
> day, month, weekday, and other existing types as duration. We are now=20
> forced to call to a function in this context which seams redundant.
After thinking more about this it could be better if the case statements=20
accepted constants of the strong type as well
using subframe =3D bounded_integer<int, 0, 9>
switch (sf) // implicit conversion using explicit int(bi)
{
case subframe{0}: ...
case subframe{1}: ...
default:
}
or
weekday wd =3D ...
switch (wd) {
case saturday: ...
case sunday: ...
default:
}
Having to define builtin integral constants associated to the underlying=20
values for the day literals would be cumbersome
weekday wd =3D ...
switch (unsigned(wd)) {
case SATURDAY: ...
case SUNDAY: ...
default:
}
The UPPER_CASE intend to be the integral constants.
Not having them will imply code that could be less readable using chained i=
f
if (saturday=3D=3Dwd)
....
else if (saunday=3D=3Dwd)
or even worst using directly the magic number of underlying value
weekday wd =3D ...
switch (unsigned(wd)) {
case 6: ...
case 0: ...
default:
}
Vicente
>
> What do you think about calling to the explicit conversion in this=20
> context?
> Is it worth changing the C++ standard language for this specific case?
>
> If not do we want to have the possibility to specialize the=20
> underlying_type trait and add the underlying function?
>
> Would the future pattern matching help on this concern? and how?
>
> 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/49ddcdf1-35cc-3601-e28c-9406fb7f639a%40wanadoo.f=
r.
--------------B008C2494AE2E56271C9CE50
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 26/04/2017 =C3=A0 21:58, Vicente J. B=
otet
Escriba a =C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:9af62eeb-49d5-9a96-d48d-e7ba761b9e75@wanadoo.fr"
type=3D"cite">
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf=
-8">
<p><font size=3D"+1">Hi,</font></p>
<p><font size=3D"+1"><br>
</font></p>
<p><font size=3D"+1">we have that instances of types with an
explicit conversion to bool can b</font>e used in if
statements, with logical operators &&, ||, and ! and
with the ?: operator.</p>
<p><br>
</p>
<p>When we have strong type wrapping integers, we need to provide
access to the underlying type and very often it is provided
using an explicit conversion.</p>
<p>However when we use a strong type in a switch we must use the
access function or cast it to the integer, as in</p>
<p>=C2=A0=C2=A0=C2=A0 switch (st.value()) {<br>
</p>
=C2=A0=C2=A0=C2=A0 ...<br>
<p>or</p>
<p>=C2=A0=C2=A0=C2=A0 switch (int(st)) {<br>
</p>
=C2=A0=C2=A0=C2=A0 ...<br>
<p>or</p>
<p>=C2=A0=C2=A0=C2=A0 switch (underlying(st)) { <br>
</p>
=C2=A0=C2=A0=C2=A0 ...<br>
<p>where underlying is a function that do the cast to the
underlying type.<br>
</p>
<p>I was wondering if we can not extend the switch statement. It
could accept any type convertible to an integral type (a type
that can be in a switch condition). If more than one of these
conversion is possible then the program will not be well formed.</p=
>
<p>switch (st) {</p>
...<br>
<br>
<br>
This could be useful where you have some generic code expecting an
Integral type. <br>
<br>
template <class Integral><br>
void f(Integral i)<br>
{<br>
<p>=C2=A0=C2=A0=C2=A0 switch (i) {<br>
</p>
=C2=A0=C2=A0=C2=A0 ...<br>
}<br>
<br>
This code will not compile if we pass it a strong integer type
wrapping an int. We would need to define a underlying function
that works for enums, int and strong integer types e.g.<br>
<br>
template <class Integral><br>
void f(Integral i)<br>
{<br>
<p>=C2=A0=C2=A0=C2=A0 switch (underlying(i)) { <br>
</p>
=C2=A0=C2=A0=C2=A0 ...<br>
}<br>
<br>
I'm expecting that we will have more and more strong types, as
e.g. day, month, weekday, and other existing types as duration. We
are now forced to call to a function in this context which seams
redundant.<br>
</blockquote>
After thinking more about this it could be better if the case
statements accepted constants of the strong type as well<br>
<p>=C2=A0=C2=A0=C2=A0 using subframe =3D bounded_integer<int, 0, 9&g=
t; </p>
<p>=C2=A0=C2=A0=C2=A0 switch (sf) // implicit conversion using explicit=
int(bi)</p>
<p>=C2=A0=C2=A0=C2=A0 {<br>
</p>
<p>=C2=A0=C2=A0=C2=A0 case subframe{0}: ...</p>
<p>=C2=A0=C2=A0=C2=A0 case subframe{1}: ...</p>
<p>=C2=A0=C2=A0=C2=A0 default:</p>
<p>=C2=A0=C2=A0=C2=A0 }</p>
<br>
or <br>
<br>
=C2=A0=C2=A0=C2=A0 weekday wd =3D ...<br>
=C2=A0=C2=A0=C2=A0 switch (wd) {<br>
=C2=A0=C2=A0=C2=A0 case saturday: ...<br>
<blockquote
cite=3D"mid:9af62eeb-49d5-9a96-d48d-e7ba761b9e75@wanadoo.fr"
type=3D"cite"> </blockquote>
=C2=A0=C2=A0=C2=A0 case sunday: ...<br>
=C2=A0=C2=A0=C2=A0 default:<br>
=C2=A0=C2=A0=C2=A0 }<br>
<br>
Having to define builtin integral constants associated to the
underlying values for the day literals would be cumbersome<br>
<br>
=C2=A0=C2=A0=C2=A0 weekday wd =3D ...<br>
=C2=A0=C2=A0=C2=A0 switch (unsigned(wd)) {<br>
=C2=A0=C2=A0=C2=A0 case SATURDAY: ...<br>
<blockquote
cite=3D"mid:9af62eeb-49d5-9a96-d48d-e7ba761b9e75@wanadoo.fr"
type=3D"cite"> </blockquote>
=C2=A0=C2=A0=C2=A0 case SUNDAY: ...<br>
=C2=A0=C2=A0=C2=A0 default:<br>
=C2=A0=C2=A0=C2=A0 }<br>
<br>
The UPPER_CASE intend to be the integral constants.<br>
<br>
Not having them will imply code that could be less readable using
chained if<br>
<br>
if (saturday=3D=3Dwd)<br>
=C2=A0=C2=A0=C2=A0 ....<br>
else if (saunday=3D=3Dwd)<br>
<br>
or even worst using directly the magic number of underlying value<br>
<br>
=C2=A0=C2=A0=C2=A0 weekday wd =3D ...<br>
=C2=A0=C2=A0=C2=A0 switch (unsigned(wd)) {<br>
=C2=A0=C2=A0=C2=A0 case 6: ...<br>
<blockquote
cite=3D"mid:9af62eeb-49d5-9a96-d48d-e7ba761b9e75@wanadoo.fr"
type=3D"cite"> </blockquote>
=C2=A0=C2=A0=C2=A0 case 0: ...<br>
=C2=A0=C2=A0=C2=A0 default:<br>
=C2=A0=C2=A0=C2=A0 }<br>
<br>
Vicente<br>
<blockquote
cite=3D"mid:9af62eeb-49d5-9a96-d48d-e7ba761b9e75@wanadoo.fr"
type=3D"cite"> <br>
What do you think about calling to the explicit conversion in this
context?<br>
Is it worth changing the C++ standard language for this specific
case?<br>
<br>
If not do we want to have the possibility to specialize the
underlying_type trait and add the underlying function?<br>
<p>Would the future pattern matching help on this concern? and
how?<br>
</p>
<p>Vicente<br>
</p>
<p><br>
</p>
</blockquote>
<p><br>
</p>
</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/49ddcdf1-35cc-3601-e28c-9406fb7f639a%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/49ddcdf1-35cc-3601-e28c-9406fb7f639a=
%40wanadoo.fr</a>.<br />
--------------B008C2494AE2E56271C9CE50--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Wed, 26 Apr 2017 13:25:21 -0700
Raw View
On Wed, Apr 26, 2017 at 1:16 PM, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
> After thinking more about this it could be better if the case statements
> accepted constants of the strong type as well
>
> using subframe = bounded_integer<int, 0, 9>
>
> switch (sf) // implicit conversion using explicit int(bi)
>
> {
>
> case subframe{0}: ...
>
> case subframe{1}: ...
>
> default:
>
> }
Does
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3627.html
meet your demand? (This paper requires your strong
types to define constexpr == and <).
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________
--
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/CAGsORuCyyKAGvT7Dv_zbf7H9AGUh09mV9_pN8bs1_VF%2B70couA%40mail.gmail.com.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 27 Apr 2017 07:47:01 +0200
Raw View
Le 26/04/2017 =C3=A0 22:25, Zhihao Yuan a =C3=A9crit :
> On Wed, Apr 26, 2017 at 1:16 PM, Vicente J. Botet Escriba
> <vicente.botet@wanadoo.fr> wrote:
>> After thinking more about this it could be better if the case statements
>> accepted constants of the strong type as well
>>
>> using subframe =3D bounded_integer<int, 0, 9>
>>
>> switch (sf) // implicit conversion using explicit int(bi)
>>
>> {
>>
>> case subframe{0}: ...
>>
>> case subframe{1}: ...
>>
>> default:
>>
>> }
> Does
>
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3627.html
>
> meet your demand? (This paper requires your strong
> types to define constexpr =3D=3D and <).
>
Yes it does. What is the status of this 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/1a1862c7-1537-f534-cccf-a9a46b51d8f6%40wanadoo.f=
r.
.
Author: Zhihao Yuan <zy@miator.net>
Date: Thu, 27 Apr 2017 13:16:44 -0500
Raw View
On Thu, Apr 27, 2017 at 12:47 AM, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
>>
> Yes it does. What is the status of this proposal?
EWG wants some design making std::string
matching against string literals cases work
out of the box (currently this paper requires
casting std::string into std::string_view), and
I don't have a good way to naturally satisfy
this requirement. Maybe you can help :)
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________
--
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/CAGsORuBh%2BRiQVyTLH%2B%2BTGQcr%2BTWnDwbTuD19ZOrVn7X4rypBYw%40mail.gmail.com.
.
Author: Dan Raviv <dan.raviv@gmail.com>
Date: Thu, 27 Apr 2017 12:41:57 -0700 (PDT)
Raw View
------=_Part_7609_1030727581.1493322117946
Content-Type: multipart/alternative;
boundary="----=_Part_7610_1994522475.1493322117946"
------=_Part_7610_1994522475.1493322117946
Content-Type: text/plain; charset=UTF-8
Hi Zhihao,
IIUC the problem is just that operator==() for std::string isn't constexpr?
(whereas it is constexpr for std::string_view). Or is there any other issue?
Cheers,
Dan
On Thursday, April 27, 2017 at 8:17:02 PM UTC+2, Zhihao Yuan wrote:
>
> On Thu, Apr 27, 2017 at 12:47 AM, Vicente J. Botet Escriba
> <vicent...@wanadoo.fr <javascript:>> wrote:
> >>
> > Yes it does. What is the status of this proposal?
>
> EWG wants some design making std::string
> matching against string literals cases work
> out of the box (currently this paper requires
> casting std::string into std::string_view), and
> I don't have a good way to naturally satisfy
> this requirement. Maybe you can help :)
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> _______________________________________________
>
--
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/3f34928c-8a35-43b3-9183-d5c53798c291%40isocpp.org.
------=_Part_7610_1994522475.1493322117946
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi Zhihao,</div><div><br></div>IIUC the problem is ju=
st that operator=3D=3D() for std::string isn't constexpr? (whereas it i=
s constexpr for std::string_view). Or is there any other issue?<div><br></d=
iv><div>Cheers,</div><div>Dan<br><div><br><br>On Thursday, April 27, 2017 a=
t 8:17:02 PM UTC+2, Zhihao Yuan wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;">On Thu, Apr 27, 2017 at 12:47 AM, Vicente J. Botet Escriba
<br><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
PSe83UxlAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">vicent...@wanadoo.fr</a>> wrote:
<br>>>
<br>> Yes it does. What is the status of this proposal?
<br>
<br>EWG wants some design making std::string
<br>matching against string literals cases work
<br>out of the box (currently this paper requires
<br>casting std::string into std::string_view), and
<br>I don't have a good way to naturally satisfy
<br>this requirement. =C2=A0Maybe you can help :)
<br>
<br>--=20
<br>Zhihao Yuan, ID lichray
<br>The best way to predict the future is to invent it.
<br>______________________________<wbr>_________________
<br></blockquote></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/3f34928c-8a35-43b3-9183-d5c53798c291%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3f34928c-8a35-43b3-9183-d5c53798c291=
%40isocpp.org</a>.<br />
------=_Part_7610_1994522475.1493322117946--
------=_Part_7609_1030727581.1493322117946--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Thu, 27 Apr 2017 16:16:12 -0500
Raw View
On Thu, Apr 27, 2017 at 2:41 PM, Dan Raviv <dan.raviv@gmail.com> wrote:
> IIUC the problem is just that operator==() for std::string isn't constexpr?
> (whereas it is constexpr for std::string_view).
Yes, plus operator<.
There can be another interpretation, that is we
lack information to compare raw string literals
other than converting them to std::string_view.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________
--
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/CAGsORuBeBJUwjRy-Grhr0Qm0Nv9W2cevdfi7t9P%2BzVvHE9-mKw%40mail.gmail.com.
.
Author: Zhihao Yuan <zy@miator.net>
Date: Thu, 27 Apr 2017 16:36:15 -0500
Raw View
On Thu, Apr 27, 2017 at 4:24 PM, Dan Raviv <dan.raviv@gmail.com> wrote:
> Ok, and is there a good reason why operator==() for std::string isn't
> constexpr? (other than it hasn't made it into the standard yet?)
It's the reason for the current proposal not able
to directly switch (/* std::string */) but it's not
the reason for why we want
std::string::operator== to be constexpr. These
two issues are not inherently dependent from
one to the other. Consider looking for a
std::string in a sequence of std::string_view,
operator== for std::string doesn't have to be
constexpr, for example, if we can deal with that
then it would benefit other types as well.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________
--
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/CAGsORuAKmGxxkjPsOEkgkJtNiojrANMjD9d_CdUos95Uzh9Pkw%40mail.gmail.com.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 27 Apr 2017 23:56:10 +0200
Raw View
This is a multi-part message in MIME format.
--------------52C36ECBC7617E61DD050F56
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 27/04/2017 =C3=A0 20:16, Zhihao Yuan a =C3=A9crit :
> On Thu, Apr 27, 2017 at 12:47 AM, Vicente J. Botet Escriba
> <vicente.botet@wanadoo.fr> wrote:
>> Yes it does. What is the status of this proposal?
> EWG wants some design making std::string
> matching against string literals cases work
> out of the box (currently this paper requires
> casting std::string into std::string_view), and
> I don't have a good way to naturally satisfy
> this requirement. Maybe you can help :)
>
This is not the use case I was looking for, but anyway.
Sorry I'm missing surely something really important.
What is the problem with string? That we don't have string literals?=20
Wouldn't require just an explicit conversion to string_view solve the issue=
?
Why not restrict it to string_view that is a literal?
Once we have constexpr_string we could as well relax the switch to this=20
type.
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/1da4b29f-b538-a1e2-406e-cf0743266e62%40wanadoo.f=
r.
--------------52C36ECBC7617E61DD050F56
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 27/04/2017 =C3=A0 20:16, Zhihao Yuan =
a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:CAGsORuBh+RiQVyTLH++TGQcr+TWnDwbTuD19ZOrVn7X4rypBYw@mail.gmail.=
com"
type=3D"cite">
<pre wrap=3D"">On Thu, Apr 27, 2017 at 12:47 AM, Vicente J. Botet Esc=
riba
<a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:vicente.botet@wanadoo.fr"=
><vicente.botet@wanadoo.fr></a> wrote:
</pre>
<blockquote type=3D"cite">
<blockquote type=3D"cite">
<pre wrap=3D"">
</pre>
</blockquote>
<pre wrap=3D"">Yes it does. What is the status of this proposal?
</pre>
</blockquote>
<pre wrap=3D"">
EWG wants some design making std::string
matching against string literals cases work
out of the box (currently this paper requires
casting std::string into std::string_view), and
I don't have a good way to naturally satisfy
this requirement. Maybe you can help :)
</pre>
</blockquote>
<p><font size=3D"+1">This is not the use case I was looking for, but
anyway. <br>
</font></p>
<p><font size=3D"+1">Sorry I'm missing surely something really
important.<br>
</font></p>
<p><font size=3D"+1">What is the problem with string? That we don't
have string literals? Wouldn't require just an explicit
conversion to string_view solve the issue?<br>
</font></p>
<p><font size=3D"+1">Why not restrict it to string_view that is a
literal?</font></p>
<p><font size=3D"+1">Once we have constexpr_string we could as well
relax the switch to this type.</font></p>
<font size=3D"+1">Vicente</font><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/1da4b29f-b538-a1e2-406e-cf0743266e62%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1da4b29f-b538-a1e2-406e-cf0743266e62=
%40wanadoo.fr</a>.<br />
--------------52C36ECBC7617E61DD050F56--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 27 Apr 2017 23:58:49 +0200
Raw View
Le 27/04/2017 =C3=A0 21:41, Dan Raviv a =C3=A9crit :
> Hi Zhihao,
>
> IIUC the problem is just that operator=3D=3D() for std::string isn't=20
> constexpr? (whereas it is constexpr for std::string_view). Or is there=20
> any other issue?
>
Why would you like a constexpr operator=3D=3D if you cannot have constexpr=
=20
strings to compare?
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/e3544184-af31-0c97-50d5-8ab4cac2a720%40wanadoo.f=
r.
.
Author: Dan Raviv <dan.raviv@gmail.com>
Date: Fri, 28 Apr 2017 00:11:28 +0200
Raw View
--001a113e59743fdc5f054e2d3e49
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Indeed. Thanks.
On Thu, Apr 27, 2017 at 11:58 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
> Le 27/04/2017 =C3=A0 21:41, Dan Raviv a =C3=A9crit :
>
>> Hi Zhihao,
>>
>> IIUC the problem is just that operator=3D=3D() for std::string isn't
>> constexpr? (whereas it is constexpr for std::string_view). Or is there a=
ny
>> other issue?
>>
>> Why would you like a constexpr operator=3D=3D if you cannot have constex=
pr
> strings to compare?
>
> Vicente
>
> --
> 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/is
> ocpp.org/d/msgid/std-proposals/e3544184-af31-0c97-50d5-
> 8ab4cac2a720%40wanadoo.fr.
>
--=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/CADw4SdRG%3Db1T%3DQNCF335wXiuTtH1c%3DFBgXpUx_DOd=
U%2BA%2BbDniA%40mail.gmail.com.
--001a113e59743fdc5f054e2d3e49
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Indeed. Thanks.<div><br></div></div><div class=3D"gmail_ex=
tra"><br><div class=3D"gmail_quote">On Thu, Apr 27, 2017 at 11:58 PM, Vicen=
te J. Botet Escriba <span dir=3D"ltr"><<a href=3D"mailto:vicente.botet@w=
anadoo.fr" target=3D"_blank">vicente.botet@wanadoo.fr</a>></span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><span class=3D"">Le 27/04/2017 =C3=A0 21=
:41, Dan Raviv a =C3=A9crit :<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Hi Zhihao,<br>
<br>
IIUC the problem is just that operator=3D=3D() for std::string isn't co=
nstexpr? (whereas it is constexpr for std::string_view). Or is there any ot=
her issue?<br>
<br>
</blockquote></span>
Why would you like a constexpr operator=3D=3D if you cannot have constexpr =
strings to compare?<br>
<br>
Vicente<span class=3D""><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 <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e3544184-af31-0c97-50d5-8ab4cac2a720%=
40wanadoo.fr" rel=3D"noreferrer" target=3D"_blank">https://groups.google.co=
m/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/e3544184-af31-0c97-50d5-<wbr=
>8ab4cac2a720%40wanadoo.fr</a>.<br>
</blockquote></div><br></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/CADw4SdRG%3Db1T%3DQNCF335wXiuTtH1c%3D=
FBgXpUx_DOdU%2BA%2BbDniA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADw4Sd=
RG%3Db1T%3DQNCF335wXiuTtH1c%3DFBgXpUx_DOdU%2BA%2BbDniA%40mail.gmail.com</a>=
..<br />
--001a113e59743fdc5f054e2d3e49--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Thu, 27 Apr 2017 17:34:02 -0500
Raw View
On Thu, Apr 27, 2017 at 4:56 PM, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
>
> What is the problem with string? That we don't have string literals?
> Wouldn't require just an explicit conversion to string_view solve the issue?
>
> Why not restrict it to string_view that is a literal?
>
> Once we have constexpr_string we could as well relax the switch to this
> type.
My understanding about string literals is that they
are initializers. Themselves do have types (array),
but these types may not convey information about
the objects they are going to initialize. string_view
or constexpr_string are not the the only types that
can be initialized from string literals, so that
string_view's ordering may be different from some
other destination types, basic_string_view<char,
CustomTraits> for example.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________
--
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/CAGsORuAcVWVEZrwXhgcveW63qirPAgNe4ygv4_6X7E5X8hm2qg%40mail.gmail.com.
.