Topic: Extensions to switch?
Author: =?UTF-8?Q?Andr=C3=A9_Becker?= <burningorca@gmail.com>
Date: Fri, 28 Sep 2018 13:12:43 -0700 (PDT)
Raw View
------=_Part_465_1534383823.1538165563302
Content-Type: multipart/alternative;
boundary="----=_Part_466_115201309.1538165563302"
------=_Part_466_115201309.1538165563302
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
This is rather a question than an actual proposal, because I am a novice=20
who has barely used the STL or experimented with the new language features=
=20
added since C++11 yet.
So I don't know how certain language constructs compile and whether there=
=20
requirements/restrictions can be changed/enhanced or lifted.
I still have two ideas regarding the switch statement - and I guess I am=20
not the first or last one having those ideas - and I just want to know if=
=20
they would be possible without breaking too much of existing code?
1. So the first one is rather syntactic sugar and my motivation behind this=
=20
is just to have more readiblity. It is combining multiple case lables into=
=20
one, for example:
void foo(int bar)
{
switch( bar )
{
case 0:
{
std::cout << "Hello, World!\n";
break;
}
case 1, 2, 3:
{
std::cout << "Hello, Universe!\n";
break;
}
case 4:
{
std::cout << "Hello, C++2whatever!\n";
break;
}
default:
{
std::cout << "I am sure this will be rejected!\n";
break;
}
}
}
which should just expand into:
void foo(int bar)
{
switch( bar )
{
case 0:
{
std::cout << "Hello, World!\n";
break;
}
case 1: [[fallthrough]];
case 2: [[fallthrough]];
case 3:
{
std::cout << "Hello, Universe!\n";
break;
}
case 4:
{
std::cout << "Hello, C++2wathever!\n";
break;
}
default:
{
std::cout << "I am sure this will be rejected!\n";
break;
}
}
}
Please consider I am very aware of that non-standard extension to the C=20
language which is only be supported by a few compilers and is written like=
=20
this:
void foo(int bar)
{
switch( bar )
{
case 0:
{
std::cout << "Hello, World!\n";
break;
}
case 0 ... 4
{
std::cout << "Hello, Universe!\n";
break;
}
case 4:
{
std::cout << "Hello, C++2wathever!\n";
break;
}
default:
{
std::cout << "I am sure this will be rejected!\n";
break;
}
}
}
I just don't like it, that is why I am not even trying to suggest=20
standardizing it. I don't like it, because as far as I know the bounds are=
=20
exclusively, which does not make it very readable for me.
As far as I know switch( x ) case n ... m is equal to if( n < x && x < m )
If the bound would be inclusively like if( n <=3D x && x <=3D m ) I would=
=20
actually like it, cause then it actually does what I expect it to do, when=
=20
looking at the statement.
2. So my second suggestion is in regards to paper P0732R0, which removes=20
many restrictions on non type template parameters by allowing class types.=
=20
One of the motivations of this paper is "generalising existing language=20
features and removing seemingly-arbitrary inconsistencies/restrictions in=
=20
the language". (Almost) the same restrictions which applied to non type=20
template parameters currently also apply to switch statements. That is why=
=20
I ask if it is possible to apply the same rules which where applied to non=
=20
type template parameters by paper P0732R0 also to the switch statement. In=
=20
this way many people may finally get their string switch:
template<typename CharT, std::size_t N>
bool operator=3D=3D(const SomeClass& a, const std::basic_fixed_string<CharT=
,=20
N>& b)
{
// Implementation
}
template<typename CharT, std::size_t N>
constexpr std::basic_fixed_string<CharT, N> bfs(CharT (&bar)[N])
{
return bar;
}
void foo(const SomeClass& a)
{
switch( a )
{
case bfs("Hello World!"):
std::cout << "You are beautiful!\n";
break;
case bfs("I hope this is a good idea!\n"):
std::cout << "Please be a good idea and become reality sometime=
=20
in the future!\n";
break;
default:
std::cout << "And if not, than maybe someone else has a good=20
idea to realize string/etc. switches in the future!\n";
}
}
The reason I want this is again readibility. In many cases, switch seems=20
more readible than a bunch of if..else if..else-blocks which all perform=20
checks on the same variable. So I sometimes feel the pain of switch being=
=20
limited to just integral constant expressions.
I personally have only one concern about this, and that is if I switch over=
=20
a object of a class, that is literally and trivially comparable according=
=20
to the rules defined by paper P0732R0,but has also a constexpr operator int=
=20
defined, which would make it already be able to be used in existing switch=
=20
statements, then the use of this object within the switch would now become=
=20
ambigious (the cases could either be int or the class type).
So the rules for this could either be:
1. Compiler error, because ambigous or
2. Operator int overrules class type and operator<=3D> in order to not brea=
k=20
existing code or
3. Something I haven't thought about.
So now my question =C3=A0re:
- Can those ideas be added to the language without breaking existing code=
=20
too much?
- Are they even desirable?
- What speaks against them?
- Can the later one maybe be achieved as a library solution? I've tried to=
=20
implement my own library switch on any type, but with the existing C++17=20
language and my novice knowlegde, I have failed to achive my goal.
As you might see, I haven't put much thought into this questions/proposals,=
=20
but I am looking forward to your comments.
Kind regards,
Andr=C3=A9
--=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/7291225c-f6a3-4c15-9794-859619155a1d%40isocpp.or=
g.
------=_Part_466_115201309.1538165563302
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This is rather a question than an actual proposal, because=
I am a novice who has barely used the STL or experimented with the new lan=
guage features added since C++11 yet.<br>So I don't know how certain la=
nguage constructs compile and whether there requirements/restrictions can b=
e changed/enhanced or lifted.<br>I still have two ideas regarding the switc=
h statement - and I guess I am not the first or last one having those ideas=
- and I just want to know if they would be possible without breaking too m=
uch of existing code?<br><br>1. So the first one is rather syntactic sugar =
and my motivation behind this is just to have more readiblity. It is combin=
ing multiple case lables into one, for example:<br>void foo(int bar)<br>{<b=
r>=C2=A0=C2=A0=C2=A0 switch( bar )<br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 0:<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 std::cout << "Hello, World!\n";<br>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;<br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 case 1, 2, 3:<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::cout <=
< "Hello, Universe!\n";<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 4:<br>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::cout << "Hello, C++2wh=
atever!\n";<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 break;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 default:<br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 std::cout << "I am sure this will be rejected=
!\n";<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 break;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=
=A0=C2=A0 }<br>}<br><br>which should just expand into:<br>void foo(int bar)=
<br>{<br>=C2=A0=C2=A0=C2=A0 switch( bar )<br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 0:<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 std::cout << "Hello, World!\n";<br>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 case 1: [[fallthrough]];<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 case 2: [[fallthrough]];<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 case 3:<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::cout << &=
quot;Hello, Universe!\n";<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 }<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 4:<br>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::cout << "Hello, C++2wathever=
!\n";<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 break;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 default:<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 std::cout << "I am sure this will be rejected!\n&qu=
ot;;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
break;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=
=A0 }<br>}<br><br>Please consider I am very aware of that non-standard exte=
nsion to the C language which is only be supported by a few compilers and i=
s written like this:<br>void foo(int bar)<br>{<br>=C2=A0=C2=A0=C2=A0 switch=
( bar )<br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 case 0:<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::cout << &=
quot;Hello, World!\n";<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 break;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 }<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 0 ... 4<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::cout << "Hello, Universe!=
\n";<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 break;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 4:<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 std::cout << "Hello, C++2wathever!\n";<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;<br>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 default:<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {<br>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::cou=
t << "I am sure this will be rejected!\n";<br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;<br>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=A0 }<br>}<br><br>I j=
ust don't like it, that is why I am not even trying to suggest standard=
izing it. I don't like it, because as far as I know the bounds are excl=
usively, which does not make it very readable for me.<br>As far as I know s=
witch( x ) case n ... m is equal to if( n < x && x < m )<br>I=
f the bound would be inclusively like if( n <=3D x && x <=3D =
m ) I would actually like it, cause then it actually does what I expect it =
to do, when looking at the statement.<br><br>2. So my second suggestion is =
in regards to paper P0732R0, which removes many restrictions on non type te=
mplate parameters by allowing class types. One of the motivations of this p=
aper is "generalising existing language features and removing seemingl=
y-arbitrary inconsistencies/restrictions in the language". (Almost) th=
e same restrictions which applied to non type template parameters currently=
also apply to switch statements. That is why I ask if it is possible to ap=
ply the same rules which where applied to non type template parameters by p=
aper P0732R0 also to the switch statement. In this way many people may fina=
lly get their string switch:<br>template<typename CharT, std::size_t N&g=
t;<br>bool operator=3D=3D(const SomeClass& a, const std::basic_fixed_st=
ring<CharT, N>& b)<br>{<br>=C2=A0=C2=A0 // Implementation<br>}<br=
><br>template<typename CharT, std::size_t N><br>constexpr std::basic_=
fixed_string<CharT, N> bfs(CharT (&bar)[N])<br>{<br>=C2=A0=C2=A0 =
return bar;<br>}<br><br>void foo(const SomeClass& a)<br>{<br>=C2=A0=C2=
=A0=C2=A0 switch( a )<br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 case bfs("Hello World!"):<br>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::cout << &quo=
t;You are beautiful!\n";<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 break;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 case bfs("I hope this is a good idea!\n"):<br>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::cout << &quo=
t;Please be a good idea and become reality sometime in the future!\n";=
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 brea=
k;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 default:<br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::cout << &=
quot;And if not, than maybe someone else has a good idea to realize string/=
etc. switches in the future!\n";<br>=C2=A0=C2=A0=C2=A0 }<br>}<br><br>T=
he reason I want this is again readibility. In many cases, switch seems mor=
e readible than a bunch of if..else if..else-blocks which all perform check=
s on the same variable. So I sometimes feel the pain of switch being limite=
d to just integral constant expressions.<br>I personally have only one conc=
ern about this, and that is if I switch over a object of a class, that is l=
iterally and trivially comparable according to the rules defined by paper P=
0732R0,but has also a constexpr operator int defined, which would make it a=
lready be able to be used in existing switch statements, then the use of th=
is object within the switch would now become ambigious (the cases could eit=
her be int or the class type).<br><br>So the rules for this could either be=
:<br>1. Compiler error, because ambigous or<br>2. Operator int overrules cl=
ass type and operator<=3D> in order to not break existing code or<br>=
3. Something I haven't thought about.<br><br>So now my question =C3=A0r=
e:<br>- Can those ideas be added to the language without breaking existing =
code too much?<br>- Are they even desirable?<br>- What speaks against them?=
<br>- Can the later one maybe be achieved as a library solution? I've t=
ried to implement my own library switch on any type, but with the existing =
C++17 language and my novice knowlegde, I have failed to achive my goal.<br=
><br>As you might see, I haven't put much thought into this questions/p=
roposals, but I am looking forward to your comments.<br><br>Kind regards,<b=
r><br>Andr=C3=A9<br><br><br><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/7291225c-f6a3-4c15-9794-859619155a1d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7291225c-f6a3-4c15-9794-859619155a1d=
%40isocpp.org</a>.<br />
------=_Part_466_115201309.1538165563302--
------=_Part_465_1534383823.1538165563302--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Fri, 28 Sep 2018 17:10:35 -0400
Raw View
--0000000000008ef1be0576f4e3f8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
https://isocpp.org/blog/2015/05/mach7-pattern-matching-for-cpp
On Fri, Sep 28, 2018 at 4:12 PM Andr=C3=A9 Becker <burningorca@gmail.com> w=
rote:
> This is rather a question than an actual proposal, because I am a novice
> who has barely used the STL or experimented with the new language feature=
s
> added since C++11 yet.
> So I don't know how certain language constructs compile and whether there
> requirements/restrictions can be changed/enhanced or lifted.
> I still have two ideas regarding the switch statement - and I guess I am
> not the first or last one having those ideas - and I just want to know if
> they would be possible without breaking too much of existing code?
>
> 1. So the first one is rather syntactic sugar and my motivation behind
> this is just to have more readiblity. It is combining multiple case lable=
s
> into one, for example:
> void foo(int bar)
> {
> switch( bar )
> {
> case 0:
> {
> std::cout << "Hello, World!\n";
> break;
> }
> case 1, 2, 3:
> {
> std::cout << "Hello, Universe!\n";
> break;
> }
> case 4:
> {
> std::cout << "Hello, C++2whatever!\n";
> break;
> }
> default:
> {
> std::cout << "I am sure this will be rejected!\n";
> break;
> }
> }
> }
>
> which should just expand into:
> void foo(int bar)
> {
> switch( bar )
> {
> case 0:
> {
> std::cout << "Hello, World!\n";
> break;
> }
> case 1: [[fallthrough]];
> case 2: [[fallthrough]];
> case 3:
> {
> std::cout << "Hello, Universe!\n";
> break;
> }
> case 4:
> {
> std::cout << "Hello, C++2wathever!\n";
> break;
> }
> default:
> {
> std::cout << "I am sure this will be rejected!\n";
> break;
> }
> }
> }
>
> Please consider I am very aware of that non-standard extension to the C
> language which is only be supported by a few compilers and is written lik=
e
> this:
> void foo(int bar)
> {
> switch( bar )
> {
> case 0:
> {
> std::cout << "Hello, World!\n";
> break;
> }
> case 0 ... 4
> {
> std::cout << "Hello, Universe!\n";
> break;
> }
> case 4:
> {
> std::cout << "Hello, C++2wathever!\n";
> break;
> }
> default:
> {
> std::cout << "I am sure this will be rejected!\n";
> break;
> }
> }
> }
>
> I just don't like it, that is why I am not even trying to suggest
> standardizing it. I don't like it, because as far as I know the bounds ar=
e
> exclusively, which does not make it very readable for me.
> As far as I know switch( x ) case n ... m is equal to if( n < x && x < m =
)
> If the bound would be inclusively like if( n <=3D x && x <=3D m ) I would
> actually like it, cause then it actually does what I expect it to do, whe=
n
> looking at the statement.
>
> 2. So my second suggestion is in regards to paper P0732R0, which removes
> many restrictions on non type template parameters by allowing class types=
..
> One of the motivations of this paper is "generalising existing language
> features and removing seemingly-arbitrary inconsistencies/restrictions in
> the language". (Almost) the same restrictions which applied to non type
> template parameters currently also apply to switch statements. That is wh=
y
> I ask if it is possible to apply the same rules which where applied to no=
n
> type template parameters by paper P0732R0 also to the switch statement. I=
n
> this way many people may finally get their string switch:
> template<typename CharT, std::size_t N>
> bool operator=3D=3D(const SomeClass& a, const std::basic_fixed_string<Cha=
rT,
> N>& b)
> {
> // Implementation
> }
>
> template<typename CharT, std::size_t N>
> constexpr std::basic_fixed_string<CharT, N> bfs(CharT (&bar)[N])
> {
> return bar;
> }
>
> void foo(const SomeClass& a)
> {
> switch( a )
> {
> case bfs("Hello World!"):
> std::cout << "You are beautiful!\n";
> break;
> case bfs("I hope this is a good idea!\n"):
> std::cout << "Please be a good idea and become reality
> sometime in the future!\n";
> break;
> default:
> std::cout << "And if not, than maybe someone else has a good
> idea to realize string/etc. switches in the future!\n";
> }
> }
>
> The reason I want this is again readibility. In many cases, switch seems
> more readible than a bunch of if..else if..else-blocks which all perform
> checks on the same variable. So I sometimes feel the pain of switch being
> limited to just integral constant expressions.
> I personally have only one concern about this, and that is if I switch
> over a object of a class, that is literally and trivially comparable
> according to the rules defined by paper P0732R0,but has also a constexpr
> operator int defined, which would make it already be able to be used in
> existing switch statements, then the use of this object within the switch
> would now become ambigious (the cases could either be int or the class
> type).
>
> So the rules for this could either be:
> 1. Compiler error, because ambigous or
> 2. Operator int overrules class type and operator<=3D> in order to not br=
eak
> existing code or
> 3. Something I haven't thought about.
>
> So now my question =C3=A0re:
> - Can those ideas be added to the language without breaking existing code
> too much?
> - Are they even desirable?
> - What speaks against them?
> - Can the later one maybe be achieved as a library solution? I've tried t=
o
> implement my own library switch on any type, but with the existing C++17
> language and my novice knowlegde, I have failed to achive my goal.
>
> As you might see, I haven't put much thought into this
> questions/proposals, but I am looking forward to your comments.
>
> Kind regards,
>
> Andr=C3=A9
>
>
>
> --
> 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/7291225c-f6a=
3-4c15-9794-859619155a1d%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7291225c-f6=
a3-4c15-9794-859619155a1d%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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/CAMD6iD8F6Utp83Poev8WP_aFraqbAPXb7aDqV8K5ECxuMxB=
qKw%40mail.gmail.com.
--0000000000008ef1be0576f4e3f8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><a href=3D"https://isocpp.org/blog/2015/0=
5/mach7-pattern-matching-for-cpp">https://isocpp.org/blog/2015/05/mach7-pat=
tern-matching-for-cpp</a><br></div></div><br><div class=3D"gmail_quote"><di=
v dir=3D"ltr">On Fri, Sep 28, 2018 at 4:12 PM Andr=C3=A9 Becker <<a href=
=3D"mailto:burningorca@gmail.com">burningorca@gmail.com</a>> wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">This is rather a quest=
ion than an actual proposal, because I am a novice who has barely used the =
STL or experimented with the new language features added since C++11 yet.<b=
r>So I don't know how certain language constructs compile and whether t=
here requirements/restrictions can be changed/enhanced or lifted.<br>I stil=
l have two ideas regarding the switch statement - and I guess I am not the =
first or last one having those ideas - and I just want to know if they woul=
d be possible without breaking too much of existing code?<br><br>1. So the =
first one is rather syntactic sugar and my motivation behind this is just t=
o have more readiblity. It is combining multiple case lables into one, for =
example:<br>void foo(int bar)<br>{<br>=C2=A0=C2=A0=C2=A0 switch( bar )<br>=
=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 0:<=
br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::cout << "Hello, =
World!\n";<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 break;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 1, 2, 3:<br>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 std::cout << "Hello, Universe!\n";<br=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;<=
br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 case 4:<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {<=
br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::=
cout << "Hello, C++2whatever!\n";<br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;<br>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 de=
fault:<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::cout << &quo=
t;I am sure this will be rejected!\n";<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=A0 }<br>}<br><br>which should just =
expand into:<br>void foo(int bar)<br>{<br>=C2=A0=C2=A0=C2=A0 switch( bar )<=
br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case =
0:<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::cout << "Hell=
o, World!\n";<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 break;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 1: [[fallthrough]];<br>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 2: [[fallthrough]];<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 3:<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 std::cout << "Hello, Universe!\n";<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;<br>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 case 4:<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {<br>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::cout &=
lt;< "Hello, C++2wathever!\n";<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 default:=
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::cout << "I am=
sure this will be rejected!\n";<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=A0 }<br>}<br><br>Please consider I am ver=
y aware of that non-standard extension to the C language which is only be s=
upported by a few compilers and is written like this:<br>void foo(int bar)<=
br>{<br>=C2=A0=C2=A0=C2=A0 switch( bar )<br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 0:<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 std::cout << "Hello, World!\n";<br>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 case 0 ... 4<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {<br>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::cou=
t << "Hello, Universe!\n";<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 4:<=
br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::cout << "Hello, =
C++2wathever!\n";<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 break;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<b=
r>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 default:<br>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 std::cout << "I am sure this will be rejec=
ted!\n";<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 break;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=
=C2=A0=C2=A0 }<br>}<br><br>I just don't like it, that is why I am not e=
ven trying to suggest standardizing it. I don't like it, because as far=
as I know the bounds are exclusively, which does not make it very readable=
for me.<br>As far as I know switch( x ) case n ... m is equal to if( n <=
; x && x < m )<br>If the bound would be inclusively like if( n &=
lt;=3D x && x <=3D m ) I would actually like it, cause then it a=
ctually does what I expect it to do, when looking at the statement.<br><br>=
2. So my second suggestion is in regards to paper P0732R0, which removes ma=
ny restrictions on non type template parameters by allowing class types. On=
e of the motivations of this paper is "generalising existing language =
features and removing seemingly-arbitrary inconsistencies/restrictions in t=
he language". (Almost) the same restrictions which applied to non type=
template parameters currently also apply to switch statements. That is why=
I ask if it is possible to apply the same rules which where applied to non=
type template parameters by paper P0732R0 also to the switch statement. In=
this way many people may finally get their string switch:<br>template<t=
ypename CharT, std::size_t N><br>bool operator=3D=3D(const SomeClass&=
; a, const std::basic_fixed_string<CharT, N>& b)<br>{<br>=C2=A0=
=C2=A0 // Implementation<br>}<br><br>template<typename CharT, std::size_=
t N><br>constexpr std::basic_fixed_string<CharT, N> bfs(CharT (&am=
p;bar)[N])<br>{<br>=C2=A0=C2=A0 return bar;<br>}<br><br>void foo(const Some=
Class& a)<br>{<br>=C2=A0=C2=A0=C2=A0 switch( a )<br>=C2=A0=C2=A0=C2=A0 =
{<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case bfs("Hello World!=
"):<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 std::cout << "You are beautiful!\n";<br>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;<br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case bfs("I hope this is a good idea!\n=
"):<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 std::cout << "Please be a good idea and become reality somet=
ime in the future!\n";<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 break;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 default:<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 std::cout << "And if not, than maybe someone else has =
a good idea to realize string/etc. switches in the future!\n";<br>=C2=
=A0=C2=A0=C2=A0 }<br>}<br><br>The reason I want this is again readibility. =
In many cases, switch seems more readible than a bunch of if..else if..else=
-blocks which all perform checks on the same variable. So I sometimes feel =
the pain of switch being limited to just integral constant expressions.<br>=
I personally have only one concern about this, and that is if I switch over=
a object of a class, that is literally and trivially comparable according =
to the rules defined by paper P0732R0,but has also a constexpr operator int=
defined, which would make it already be able to be used in existing switch=
statements, then the use of this object within the switch would now become=
ambigious (the cases could either be int or the class type).<br><br>So the=
rules for this could either be:<br>1. Compiler error, because ambigous or<=
br>2. Operator int overrules class type and operator<=3D> in order to=
not break existing code or<br>3. Something I haven't thought about.<br=
><br>So now my question =C3=A0re:<br>- Can those ideas be added to the lang=
uage without breaking existing code too much?<br>- Are they even desirable?=
<br>- What speaks against them?<br>- Can the later one maybe be achieved as=
a library solution? I've tried to implement my own library switch on a=
ny type, but with the existing C++17 language and my novice knowlegde, I ha=
ve failed to achive my goal.<br><br>As you might see, I haven't put muc=
h thought into this questions/proposals, but I am looking forward to your c=
omments.<br><br>Kind regards,<br><br>Andr=C3=A9<br><br><br><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" 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/7291225c-f6a3-4c15-9794-859619155a1d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7291225c-f6a3-=
4c15-9794-859619155a1d%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/CAMD6iD8F6Utp83Poev8WP_aFraqbAPXb7aDq=
V8K5ECxuMxBqKw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD8F6Utp83Po=
ev8WP_aFraqbAPXb7aDqV8K5ECxuMxBqKw%40mail.gmail.com</a>.<br />
--0000000000008ef1be0576f4e3f8--
.
Author: =?UTF-8?Q?Andr=C3=A9_Becker?= <burningorca@gmail.com>
Date: Fri, 28 Sep 2018 19:56:15 -0700 (PDT)
Raw View
------=_Part_620_76005937.1538189775812
Content-Type: multipart/alternative;
boundary="----=_Part_621_940624257.1538189775812"
------=_Part_621_940624257.1538189775812
Content-Type: text/plain; charset="UTF-8"
Thanks, obviously I did not know about that.
Is the mach7 library standard are going to become standard?
For me it seems it is highly macro based, no wonder I couldn't do that
myself, trying to not use macros.
--
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/1e978f22-fcf0-459c-8090-ec1de4859ef6%40isocpp.org.
------=_Part_621_940624257.1538189775812
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Thanks, obviously I did not know about that.</div><di=
v>Is the mach7 library standard are going to become standard?</div><div>For=
me it seems it is highly macro based, no wonder I couldn't do that mys=
elf, trying to not use macros.<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/1e978f22-fcf0-459c-8090-ec1de4859ef6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1e978f22-fcf0-459c-8090-ec1de4859ef6=
%40isocpp.org</a>.<br />
------=_Part_621_940624257.1538189775812--
------=_Part_620_76005937.1538189775812--
.
Author: =?UTF-8?Q?Andr=C3=A9_Becker?= <burningorca@gmail.com>
Date: Fri, 28 Sep 2018 21:40:16 -0700 (PDT)
Raw View
------=_Part_670_527139421.1538196016798
Content-Type: multipart/alternative;
boundary="----=_Part_671_1139722215.1538196016798"
------=_Part_671_1139722215.1538196016798
Content-Type: text/plain; charset="UTF-8"
Wow now I deleted my first entry, because I thought the whole topic will be
deleted this way.
Now anybody else, which clicks on this topic won't know what all was about.
But I already have the best answer, so I guess this doesn't matter.
--
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/861d2dbf-5d21-4a77-8154-5223d180c8b7%40isocpp.org.
------=_Part_671_1139722215.1538196016798
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Wow now I deleted my first entry, because I thought t=
he whole topic will be deleted this way.</div><div>Now anybody else, which =
clicks on this topic won't know what all was about. But I already have =
the best answer, so I guess this doesn't matter.<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/861d2dbf-5d21-4a77-8154-5223d180c8b7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/861d2dbf-5d21-4a77-8154-5223d180c8b7=
%40isocpp.org</a>.<br />
------=_Part_671_1139722215.1538196016798--
------=_Part_670_527139421.1538196016798--
.