Il giorno 07/nov/2014, alle ore 00:14, Sean Hunt <scshunt@csclub.uwaterloo.=
ca> ha scritto:
>=20
> Hey fellow language geeks,
>=20

Hi!

> I vaguely recall that, a long time ago, I submitted a similar proposal to=
 comp.std.c++ to lukewarm reception, but I can't dig it up and the language=
 and process have evolved a lot, so I figured it might be interesting to se=
e what current people think.
>=20
> Currently, there is no thrust towards getting a relaxed switch statement =
into the language, but the EWG did express some interest in continuing with=
 N3627,[1] which proposes a much more restricted version than I propose her=
e.
>=20
> The general concept is to allow a fully overloadable switch operator. The=
 inspiration comes from Perl's experimental smart match operator,[2] which =
is designed to make the code "do the right thing" in the context of a switc=
h.
>=20
> The first component is the addition of a new overloadable operator name. =
We could use a magic name function name like begin() and end(), but that's =
really a bikeshedding problem and doesn't affect the substance of the propo=
sal, I think.
>=20
> The new operator, "operator switch", must return bool and take exactly tw=
o arguments (optionally, we could allow a one-argument member form as well)=
.. As an example, we might have:
>=20
> bool operator switch(const std::regex& re, const std::string &s) {
>     return regex_match(s, re, std::match_any);
> }
>=20
> The use of this operator is straightforward. switch(s) { case e: ; } is r=
oughly translated to "if (operator switch(e, s)) ; ". In case of multiple p=
ossible matches, the first one is chosen. Existing switch behaviour is impl=
emented with implicit overload candidates, as with built-in operators.
>=20
> So as an example, assuming a UDL for regexes exists, you could do:
>=20
> switch (some_long_string) {
> case "(a )?colou?red house"_regex:
>     std::cout << "coloured house";
>     break;
> case "(a )?house"_regex:
>     std::cout << "house";
>     break;
> default:
>     std::cout << "dunno";
>     break;
> }
>=20
> Rather than have "default" mean "true", I would rather preserve the exist=
ing behaviour that default is fallen back onto whenever none of the case ex=
pressions match.
>=20
> The biggest potential issue with this is reuse of conversions. Because ne=
w expressions need to be evaluated on the matching expression, there is no =
consistent way to minimize conversions like the current switch does (where =
a value is converted to integer type only once). In the above example, if s=
ome_long_string is not a string, but is convertible to one, is the conversi=
on called multiple times? Perhaps it could be unspecified whether a convers=
ion function is called more than once in the evaluation of a switch---this =
would help ensure that implementations can continue to use optimizations li=
ke jump tables for builtin types. Other options may include requiring expli=
cit specification of the type ("switch std::string (some_long_string)"), wh=
ich, if not specified, gives the non-overloaded switch behaviour ("switch a=
uto(e)" could be used for getting the new behaviour with the type of e) or =
restricting the implicit conversions that can be performed.
>=20
> Thoughts?
>=20

I think it's interesting! A couple of thoughts:

The current switch can be implemented in a very efficient way because of it=
s restriction to integral types and constant labels. I think it is worth to=
 extend it, but there should be a way to make it at least as fast for some =
case of user defined overloads.
What is needed is:=20
1) a way to specify if you want your labels to be constexpr, and/or a way t=
o define the overload to take template parameters instead of function param=
eters (similar to how UDL work).

2) a way to overload the switch by considering all the labels at once. In a=
 lot of cases it could be much more efficient to match against all the labe=
ls rather than one at the time. This overload could take a variadic argumen=
t pack and return the index of the matching label. This way the jumping log=
ic could continue to be implemented as efficient jump tables. Of course if =
the user would have to iterate over the pack, then it could simply overload=
 the single argument version and let the language do the work, but if it ca=
n take advantage of having all the labels to implement a faster matching, t=
han it can do it.=20

One extra thought is that if C++ wants to add such an extended switch, perh=
aps it is worth exploring a way to add full pattern matching capabilities t=
o the language. I want to see something like this (where Leaf and Node are =
concrete subclasses of Tree, with the suitable operator defined):

void visit(Tree *node) {
  switch(node) {
  case Leaf(x):=20
    std::cout << x << std::endl;
    break;
  case Node(l, r):
    visit(l);
    visit(r);
    break;
  }
}

> Sean
>=20

Bye,
Nicola

--=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_518_193847235.1415354007691
Content-Type: text/plain; charset=UTF-8

I don't think it's a bad idea but I think there are betters ways to achieve
this via a sub-set of pattern matching found in functiona languages like
Haskell & F# in particular case/match expressions (both languages also have
extensible pattern matching called Active/View patterns)

There is already some work being done for adding just such a feature to
C++. First as a library solution and then hopefully becoming a language
feature:

https://github.com/CppCon/CppCon2014/tree/master/Presentations/Accept%20No%20Visitors

videos:
https://www.youtube.com/watch?v=OkDS6hmU-w8
https://www.youtube.com/watch?v=QhJguzpZOrk

You may see some emphasis on visitor pattern/double dispatch but pattern
matching isn't a feature to only give a better solution this particular
problem it is more general than that and is applicable to
sub-string/regular expression matching.

I'd would rather see more effort & work made in to eventually adding
support for full pattern matching capabilities to C++. For example pattern
matching on tuples, variants/algebraic data-types, records, etc outside of
the context of just case/match expressions.

On Thursday, November 6, 2014 11:14:17 PM UTC, Sean Hunt wrote:
>
> Hey fellow language geeks,
>
> I vaguely recall that, a long time ago, I submitted a similar proposal to
> comp.std.c++ to lukewarm reception, but I can't dig it up and the language
> and process have evolved a lot, so I figured it might be interesting to see
> what current people think.
>
> Currently, there is no thrust towards getting a relaxed switch statement
> into the language, but the EWG did express some interest in continuing with
> N3627,[1] which proposes a much more restricted version than I propose here.
>
> The general concept is to allow a fully overloadable switch operator. The
> inspiration comes from Perl's experimental smart match operator,[2] which
> is designed to make the code "do the right thing" in the context of a
> switch.
>
> The first component is the addition of a new overloadable operator name.
> We could use a magic name function name like begin() and end(), but that's
> really a bikeshedding problem and doesn't affect the substance of the
> proposal, I think.
>
> The new operator, "operator switch", must return bool and take exactly two
> arguments (optionally, we could allow a one-argument member form as well).
> As an example, we might have:
>
> bool operator switch(const std::regex& re, const std::string &s) {
>     return regex_match(s, re, std::match_any);
> }
>
> The use of this operator is straightforward. switch(s) { case e: ; } is
> roughly translated to "if (operator switch(e, s)) ; ". In case of multiple
> possible matches, the first one is chosen. Existing switch behaviour is
> implemented with implicit overload candidates, as with built-in operators.
>
> So as an example, assuming a UDL for regexes exists, you could do:
>
> switch (some_long_string) {
> case "(a )?colou?red house"_regex:
>     std::cout << "coloured house";
>     break;
> case "(a )?house"_regex:
>     std::cout << "house";
>     break;
> default:
>     std::cout << "dunno";
>     break;
> }
>
> Rather than have "default" mean "true", I would rather preserve the
> existing behaviour that default is fallen back onto whenever none of the
> case expressions match.
>
> The biggest potential issue with this is reuse of conversions. Because new
> expressions need to be evaluated on the matching expression, there is no
> consistent way to minimize conversions like the current switch does (where
> a value is converted to integer type only once). In the above example, if
> some_long_string is not a string, but is convertible to one, is the
> conversion called multiple times? Perhaps it could be unspecified whether a
> conversion function is called more than once in the evaluation of a
> switch---this would help ensure that implementations can continue to use
> optimizations like jump tables for builtin types. Other options may include
> requiring explicit specification of the type ("switch std::string
> (some_long_string)"), which, if not specified, gives the non-overloaded
> switch behaviour ("switch auto(e)" could be used for getting the new
> behaviour with the type of e) or restricting the implicit conversions that
> can be performed.
>
> Thoughts?
>
> Sean
>
> [1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3627.html
> [2]: http://perldoc.perl.org/perlop.html#Smartmatch-Operator
>

--

---
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_518_193847235.1415354007691
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I don't think it's a bad idea but I think there are better=
s ways to achieve this via a sub-set of pattern matching found in functiona=
 languages like Haskell &amp; F# in particular case/match expressions (both=
 languages also have extensible pattern matching called Active/View pattern=
s)<br><br>There is already some work being done for adding just such a feat=
ure to C++. First as a library solution and then hopefully becoming a langu=
age feature:<br><br>https://github.com/CppCon/CppCon2014/tree/master/Presen=
tations/Accept%20No%20Visitors<br><br>videos:<br>https://www.youtube.com/wa=
tch?v=3DOkDS6hmU-w8<br>https://www.youtube.com/watch?v=3DQhJguzpZOrk<br><br=
>You may see some emphasis on visitor pattern/double dispatch but pattern m=
atching isn't a feature to only give a better solution this particular prob=
lem it is more general than that and is applicable to sub-string/regular ex=
pression matching.<br><br>I'd would rather see more effort &amp; work made =
in to eventually adding support for full pattern matching capabilities to C=
++. For example pattern matching on tuples, variants/algebraic data-types, =
records, etc outside of the context of just case/match expressions.<br><br>=
On Thursday, November 6, 2014 11:14:17 PM UTC, Sean Hunt wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Hey fellow language geeks=
,<div><br></div><div>I vaguely recall that, a long time ago, I submitted a =
similar proposal to comp.std.c++ to lukewarm reception, but I can't dig it =
up and the language and process have evolved a lot, so I figured it might b=
e interesting to see what current people think.</div><div><br></div><div>Cu=
rrently, there is no thrust towards getting a relaxed switch statement into=
 the language, but the EWG did express some interest in continuing with N36=
27,[1] which proposes a much more restricted version than I propose here.</=
div><div><br></div><div>The general concept is to allow a fully overloadabl=
e switch operator. The inspiration comes from Perl's experimental smart mat=
ch operator,[2] which is designed to make the code "do the right thing" in =
the context of a switch.</div><div><br></div><div>The first component is th=
e addition of a new overloadable operator name. We could use a magic name f=
unction name like begin() and end(), but that's really a bikeshedding probl=
em and doesn't affect the substance of the proposal, I think.</div><div><br=
></div><div>The new operator, "operator switch", must return bool and take =
exactly two arguments (optionally, we could allow a one-argument member for=
m as well). As an example, we might have:</div><div><br></div><div>bool ope=
rator switch(const std::regex&amp; re, const std::string &amp;s) {</div><di=
v>&nbsp; &nbsp; return regex_match(s, re, std::match_any);</div><div>}</div=
><div><br></div><div>The use of this operator is straightforward. switch(s)=
 { case e: ; } is roughly translated to "if (operator switch(e, s)) ; ". In=
 case of multiple possible matches, the first one is chosen. Existing switc=
h behaviour is implemented with implicit overload candidates, as with built=
-in operators.</div><div><br></div><div>So as an example, assuming a UDL fo=
r regexes exists, you could do:</div><div><br></div><div>switch (some_long_=
string) {</div><div>case "(a )?colou?red house"_regex:</div><div>&nbsp; &nb=
sp; std::cout &lt;&lt; "coloured house";</div><div>&nbsp; &nbsp; break;</di=
v><div>case "(a )?house"_regex:</div><div>&nbsp; &nbsp; std::cout &lt;&lt; =
"house";</div><div>&nbsp; &nbsp; break;</div><div>default:</div><div>&nbsp;=
 &nbsp; std::cout &lt;&lt; "dunno";</div><div>&nbsp; &nbsp; break;</div><di=
v>}</div><div><br></div><div>Rather than have "default" mean "true", I woul=
d rather preserve the existing behaviour that default is fallen back onto w=
henever none of the case expressions match.</div><div><br></div><div>The bi=
ggest potential issue with this is reuse of conversions. Because new expres=
sions need to be evaluated on the matching expression, there is no consiste=
nt way to minimize conversions like the current switch does (where a value =
is converted to integer type only once). In the above example, if some_long=
_string is not a string, but is convertible to one, is the conversion calle=
d multiple times? Perhaps it could be unspecified whether a conversion func=
tion is called more than once in the evaluation of a switch---this would he=
lp ensure that implementations can continue to use optimizations like jump =
tables for builtin types. Other options may include requiring explicit spec=
ification of the type ("switch std::string (some_long_string)"), which, if =
not specified, gives the non-overloaded switch behaviour ("switch auto(e)" =
could be used for getting the new behaviour with the type of e) or restrict=
ing the implicit conversions that can be performed.</div><div><br></div><di=
v>Thoughts?</div><div><br></div><div>Sean</div><div><br></div><div>[1]: <a =
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3627.html"=
 target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\=
75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013=
%2Fn3627.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHhYBhfwsa3w0WmYfE9-q-ZNHJ-=
dQ';return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75htt=
p%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3=
627.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHhYBhfwsa3w0WmYfE9-q-ZNHJ-dQ';r=
eturn true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2013/<=
wbr>n3627.html</a><br></div><div>[2]: <a href=3D"http://perldoc.perl.org/pe=
rlop.html#Smartmatch-Operator" target=3D"_blank" onmousedown=3D"this.href=
=3D'http://www.google.com/url?q\75http%3A%2F%2Fperldoc.perl.org%2Fperlop.ht=
ml%23Smartmatch-Operator\46sa\75D\46sntz\0751\46usg\75AFQjCNHE_IUbPRt6h05Yz=
jxnxu557g3NHQ';return true;" onclick=3D"this.href=3D'http://www.google.com/=
url?q\75http%3A%2F%2Fperldoc.perl.org%2Fperlop.html%23Smartmatch-Operator\4=
6sa\75D\46sntz\0751\46usg\75AFQjCNHE_IUbPRt6h05Yzjxnxu557g3NHQ';return true=
;">http://perldoc.perl.org/<wbr>perlop.html#Smartmatch-<wbr>Operator</a></d=
iv></div></blockquote></div>

<p></p>

-- <br />
<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 <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 />
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 />

------=_Part_518_193847235.1415354007691--

.

--089e0160b87497ad6a050744d6a9
Content-Type: text/plain; charset=UTF-8

You can implement already do this with a lambda switch:

regex_switch (some_long_string,
"(a )?colou?red house", [] {
    std::cout << "coloured house";
},
"(a )?house", [] {
    std::cout << "house";
},
regex_switch_default, [] {
    std::cout << "dunno";
    break;
}
);

While arguable not as "beautiful" as a core language feature, this way has
the benefit of not further complicating the already overly-complex core
language.
  -Andrew.


On Fri, Nov 7, 2014 at 12:14 AM, Sean Hunt <scshunt@csclub.uwaterloo.ca>
wrote:

> Hey fellow language geeks,
>
> I vaguely recall that, a long time ago, I submitted a similar proposal to
> comp.std.c++ to lukewarm reception, but I can't dig it up and the language
> and process have evolved a lot, so I figured it might be interesting to see
> what current people think.
>
> Currently, there is no thrust towards getting a relaxed switch statement
> into the language, but the EWG did express some interest in continuing with
> N3627,[1] which proposes a much more restricted version than I propose here.
>
> The general concept is to allow a fully overloadable switch operator. The
> inspiration comes from Perl's experimental smart match operator,[2] which
> is designed to make the code "do the right thing" in the context of a
> switch.
>
> The first component is the addition of a new overloadable operator name.
> We could use a magic name function name like begin() and end(), but that's
> really a bikeshedding problem and doesn't affect the substance of the
> proposal, I think.
>
> The new operator, "operator switch", must return bool and take exactly two
> arguments (optionally, we could allow a one-argument member form as well).
> As an example, we might have:
>
> bool operator switch(const std::regex& re, const std::string &s) {
>     return regex_match(s, re, std::match_any);
> }
>
> The use of this operator is straightforward. switch(s) { case e: ; } is
> roughly translated to "if (operator switch(e, s)) ; ". In case of multiple
> possible matches, the first one is chosen. Existing switch behaviour is
> implemented with implicit overload candidates, as with built-in operators.
>
> So as an example, assuming a UDL for regexes exists, you could do:
>
> switch (some_long_string) {
> case "(a )?colou?red house"_regex:
>     std::cout << "coloured house";
>     break;
> case "(a )?house"_regex:
>     std::cout << "house";
>     break;
> default:
>     std::cout << "dunno";
>     break;
> }
>
> Rather than have "default" mean "true", I would rather preserve the
> existing behaviour that default is fallen back onto whenever none of the
> case expressions match.
>
> The biggest potential issue with this is reuse of conversions. Because new
> expressions need to be evaluated on the matching expression, there is no
> consistent way to minimize conversions like the current switch does (where
> a value is converted to integer type only once). In the above example, if
> some_long_string is not a string, but is convertible to one, is the
> conversion called multiple times? Perhaps it could be unspecified whether a
> conversion function is called more than once in the evaluation of a
> switch---this would help ensure that implementations can continue to use
> optimizations like jump tables for builtin types. Other options may include
> requiring explicit specification of the type ("switch std::string
> (some_long_string)"), which, if not specified, gives the non-overloaded
> switch behaviour ("switch auto(e)" could be used for getting the new
> behaviour with the type of e) or restricting the implicit conversions that
> can be performed.
>
> Thoughts?
>
> Sean
>
> [1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3627.html
> [2]: http://perldoc.perl.org/perlop.html#Smartmatch-Operator
>
> --
>
> ---
> 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/.
>

--

---
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/.

--089e0160b87497ad6a050744d6a9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">You can implement already do this with a lambda switch:<di=
v><br></div><div><div style=3D"font-family:arial,sans-serif;font-size:13px"=
>regex_switch (some_long_string,</div><div style=3D"font-family:arial,sans-=
serif;font-size:13px">&quot;(a )?colou?red house&quot;, [] {</div><div styl=
e=3D"font-family:arial,sans-serif;font-size:13px">=C2=A0 =C2=A0 std::cout &=
lt;&lt; &quot;coloured house&quot;;</div><div style=3D"font-family:arial,sa=
ns-serif;font-size:13px">},</div><div style=3D"font-family:arial,sans-serif=
;font-size:13px">&quot;(a )?house&quot;, [] {<br></div><div style=3D"font-f=
amily:arial,sans-serif;font-size:13px">=C2=A0 =C2=A0 std::cout &lt;&lt; &qu=
ot;house&quot;;</div><div style=3D"font-family:arial,sans-serif;font-size:1=
3px">},</div><div style=3D"font-family:arial,sans-serif;font-size:13px">reg=
ex_switch_default, [] {</div><div style=3D"font-family:arial,sans-serif;fon=
t-size:13px">=C2=A0 =C2=A0 std::cout &lt;&lt; &quot;dunno&quot;;</div><div =
style=3D"font-family:arial,sans-serif;font-size:13px">=C2=A0 =C2=A0 break;<=
/div><div style=3D"font-family:arial,sans-serif;font-size:13px">}</div></di=
v><div style=3D"font-family:arial,sans-serif;font-size:13px">);</div><div s=
tyle=3D"font-family:arial,sans-serif;font-size:13px"><br></div><div style=
=3D"font-family:arial,sans-serif;font-size:13px">While arguable not as &quo=
t;beautiful&quot; as a core language feature, this way has the benefit of n=
ot further complicating the already overly-complex core language.</div><div=
 style=3D"font-family:arial,sans-serif;font-size:13px">=C2=A0 -Andrew.</div=
><div style=3D"font-family:arial,sans-serif;font-size:13px"><br></div></div=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Nov 7, 2=
014 at 12:14 AM, Sean Hunt <span dir=3D"ltr">&lt;<a href=3D"mailto:scshunt@=
csclub.uwaterloo.ca" target=3D"_blank">scshunt@csclub.uwaterloo.ca</a>&gt;<=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hey fellow=
 language geeks,<div><br></div><div>I vaguely recall that, a long time ago,=
 I submitted a similar proposal to comp.std.c++ to lukewarm reception, but =
I can&#39;t dig it up and the language and process have evolved a lot, so I=
 figured it might be interesting to see what current people think.</div><di=
v><br></div><div>Currently, there is no thrust towards getting a relaxed sw=
itch statement into the language, but the EWG did express some interest in =
continuing with N3627,[1] which proposes a much more restricted version tha=
n I propose here.</div><div><br></div><div>The general concept is to allow =
a fully overloadable switch operator. The inspiration comes from Perl&#39;s=
 experimental smart match operator,[2] which is designed to make the code &=
quot;do the right thing&quot; in the context of a switch.</div><div><br></d=
iv><div>The first component is the addition of a new overloadable operator =
name. We could use a magic name function name like begin() and end(), but t=
hat&#39;s really a bikeshedding problem and doesn&#39;t affect the substanc=
e of the proposal, I think.</div><div><br></div><div>The new operator, &quo=
t;operator switch&quot;, must return bool and take exactly two arguments (o=
ptionally, we could allow a one-argument member form as well). As an exampl=
e, we might have:</div><div><br></div><div>bool operator switch(const std::=
regex&amp; re, const std::string &amp;s) {</div><div>=C2=A0 =C2=A0 return r=
egex_match(s, re, std::match_any);</div><div>}</div><div><br></div><div>The=
 use of this operator is straightforward. switch(s) { case e: ; } is roughl=
y translated to &quot;if (operator switch(e, s)) ; &quot;. In case of multi=
ple possible matches, the first one is chosen. Existing switch behaviour is=
 implemented with implicit overload candidates, as with built-in operators.=
</div><div><br></div><div>So as an example, assuming a UDL for regexes exis=
ts, you could do:</div><div><br></div><div>switch (some_long_string) {</div=
><div>case &quot;(a )?colou?red house&quot;_regex:</div><div>=C2=A0 =C2=A0 =
std::cout &lt;&lt; &quot;coloured house&quot;;</div><div>=C2=A0 =C2=A0 brea=
k;</div><div>case &quot;(a )?house&quot;_regex:</div><div>=C2=A0 =C2=A0 std=
::cout &lt;&lt; &quot;house&quot;;</div><div>=C2=A0 =C2=A0 break;</div><div=
>default:</div><div>=C2=A0 =C2=A0 std::cout &lt;&lt; &quot;dunno&quot;;</di=
v><div>=C2=A0 =C2=A0 break;</div><div>}</div><div><br></div><div>Rather tha=
n have &quot;default&quot; mean &quot;true&quot;, I would rather preserve t=
he existing behaviour that default is fallen back onto whenever none of the=
 case expressions match.</div><div><br></div><div>The biggest potential iss=
ue with this is reuse of conversions. Because new expressions need to be ev=
aluated on the matching expression, there is no consistent way to minimize =
conversions like the current switch does (where a value is converted to int=
eger type only once). In the above example, if some_long_string is not a st=
ring, but is convertible to one, is the conversion called multiple times? P=
erhaps it could be unspecified whether a conversion function is called more=
 than once in the evaluation of a switch---this would help ensure that impl=
ementations can continue to use optimizations like jump tables for builtin =
types. Other options may include requiring explicit specification of the ty=
pe (&quot;switch std::string (some_long_string)&quot;), which, if not speci=
fied, gives the non-overloaded switch behaviour (&quot;switch auto(e)&quot;=
 could be used for getting the new behaviour with the type of e) or restric=
ting the implicit conversions that can be performed.</div><div><br></div><d=
iv>Thoughts?</div><div><br></div><div>Sean</div><div><br></div><div>[1]: <a=
 href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3627.html=
" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013=
/n3627.html</a><br></div><div>[2]: <a href=3D"http://perldoc.perl.org/perlo=
p.html#Smartmatch-Operator" target=3D"_blank">http://perldoc.perl.org/perlo=
p.html#Smartmatch-Operator</a></div></div><span class=3D"HOEnZb"><font colo=
r=3D"#888888">

<p></p>

-- <br>
<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 <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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
<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 <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 />
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 />

--089e0160b87497ad6a050744d6a9--

.