Hi,

When I was reading Imperfect C++, I feel disappointed as same
as the author when I found that the following code does no work:

  switch(s)
  {
    case "abc":
   ...
  }

Generally, in `switch(_ie_)`, _ie_ is required to be implicitly
convertible to int, and in `case: _e_:`, _e_ should be an const
expression.  The latter one is reasonable, but the first one
is not.  Since we have `constexpr`, I don't see there is a
drawback to relax the first restriction to "a object of a literal type
comparable with == but not implicitly convertible to integer, or
an object implicitly convertible to integer".

With this change and "N3468: User-defined Literals for
Standard Library Types",
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3468.pdf
we will be able to use the nice UDL syntax in `case`!

Let's go back to the `case "abc":`.  *One more reason* to
give ""s to `string_ref` -- a literal type.

Hope we can write

  switch(s)
  {
    case "abc"s:
   ...
  }

one day.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 2:05 AM, Zhihao Yuan <lichray@gmail.com> wrote:
> Let's go back to the `case "abc":`.  *One more reason* to
> give ""s to `string_ref` -- a literal type.

I carefully read the standard and find that the syntax

  case "abc"s:

is not needed with my proposed change.  Because the expression
after `case` is a _converted constant expression_, and `string_ref`
already has a constexpr c'tor to implicitly convert a `char const *`.
However, as stated in one of my past email, "abc"s is still required
for a string with embedded NULs.

With a _converted constant expression_, I hope a uniform
initialization can be used here when a UDL is not provided:

  switch (e) {
  case { 3, 4 }:

which is equivalent to

  switch (e) {
  case T{ 3, 4 }:

where T is `std::remove_reference<decltype(e)>::type`, and
`T{3, 4}` is a _literal constant expression_ of type T.

Last but not least, since `std::complex<double>` is proposed
to be allowed, there is no reason to do not allow `double`.
So _e_ inside `switch(_e_)` should include:

 1. Integral or enum, or class type implicitly convertible to
    integral or enum; // integral promotion
 2. Floating point; // floating point promotion (?)
 3. Literal type which is not implicitly convertible to integral
    or enum.

For (2), since floating point conversion is not allowed in
a _converted constant expression_, we have to write the
`l` (and `f`, see(?)) suffix in `case`s.  IMO, this is a safe why.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On 1/24/13, Zhihao Yuan <lichray@gmail.com> wrote:
> Hi,
>
> When I was reading Imperfect C++, I feel disappointed as same
> as the author when I found that the following code does no work:
>
>   switch(s)
>   {
>     case "abc":
>    ...
>   }
>
> Generally, in `switch(_ie_)`, _ie_ is required to be implicitly
> convertible to int, and in `case: _e_:`, _e_ should be an const
> expression.  The latter one is reasonable, but the first one
> is not.  Since we have `constexpr`, I don't see there is a
> drawback to relax the first restriction to "a object of a literal type
> comparable with == but not implicitly convertible to integer, or
> an object implicitly convertible to integer".
>
> With this change and "N3468: User-defined Literals for
> Standard Library Types",
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3468.pdf
> we will be able to use the nice UDL syntax in `case`!
>
> Let's go back to the `case "abc":`.  *One more reason* to
> give ""s to `string_ref` -- a literal type.
>
> Hope we can write
>
>   switch(s)
>   {
>     case "abc"s:
>    ...
>   }
>
> one day.

How would this feature result in code that is significantly
better than a simple if else if else chain?

--
Lawrence Crowl

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 3:40 PM, Lawrence Crowl <crowl@googlers.com> wrote:
> How would this feature result in code that is significantly
> better than a simple if else if else chain?

1. Syntax matters.  SYNTAX MATTERS.
2. `case "abc":` is required to be evaluated at compile time,
   while the initialization of a temporary object from "abc" in
   `if (e == "abc")` is not.


--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 1:45 PM, Zhihao Yuan <lichray@gmail.com> wrote:
> On Thu, Jan 24, 2013 at 3:40 PM, Lawrence Crowl <crowl@googlers.com> wrote:
>> How would this feature result in code that is significantly
>> better than a simple if else if else chain?
>
> 1. Syntax matters.  SYNTAX MATTERS.
> 2. `case "abc":` is required to be evaluated at compile time,
>    while the initialization of a temporary object from "abc" in
>    `if (e == "abc")` is not.

While I'm sympathetic to the "strings should be usable in switches"
position, I'm not sympathetic to arguments based on "some compiler
missed an optimization that other compilers catch."

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 3:50 PM, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
> I'm not sympathetic to arguments based on "some compiler
> missed an optimization that other compilers catch."

OK.  This is not an argument.  It's just a result that I can think of.

Not just strings, of course.  Currently, floating points, UDL,
{ initializers }.  Not sure whether std::array is an literal type.
If so, `case { "a", "abc", ... }:`.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On 1/24/13, Zhihao Yuan <lichray@gmail.com> wrote:
> On Jan 24, 2013 Lawrence Crowl <crowl@googlers.com> wrote:
> > How would this feature result in code that is significantly
> > better than a simple if else if else chain?
>
> 1. Syntax matters.  SYNTAX MATTERS.

Agreed.  However, the benefit of new syntax must be weighed against
its cost.  I'm asking you to explain why you think the benefit
is significant.

> 2. `case "abc":` is required to be evaluated at compile time,
> while the initialization of a temporary object from "abc" in
> `if (e == "abc")` is not.

And why is that important?

--
Lawrence Crowl

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 3:58 PM, Lawrence Crowl <crowl@googlers.com> wrote:
>> 1. Syntax matters.  SYNTAX MATTERS.
>
> Agreed.  However, the benefit of new syntax must be weighed against
> its cost.  I'm asking you to explain why you think the benefit
> is significant.

First, my suggestion breaks no existing code, practice.  It's just
a relax on the syntax, like allowing `if (auto i == e)`.

If I'm being asked "is there a *significant* between `if...else` and
the relaxed `switch...case` like as significant as the difference
between `int i = e; if (i)` and `if (int i = e)`", I can only think of
one thing:

  if (e == { 3, 4 })  // wrong syntax; use either operator== or cast

But to allow { initializers } inside `case e:` is not that complex.
However, I'm not sure whether this is significant.


--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 4:13 PM, Zhihao Yuan <lichray@gmail.com> wrote:
> I can only think of one thing [...]

Forgot, with the control flow of switch...case, there are others.

1. No way to "break" an "if...else if" without a goto or return;
2. Fall through:

  case "a":
    // do something first
  case "abc":
    // plus some other things

   -- very useful logic.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 5:29 AM, Zhihao Yuan <lichray@gmail.com> wrote:
> For (2), since floating point conversion is not allowed in
> a _converted constant expression_, we have to write the
> `l` (and `f`, see(?)) suffix in `case`s.  IMO, this is a safe why.

Requiring an exact match on the types of the floating points appears
in `switch (e)` and `case e:` makes generic code impossible:

  switch (e) {
    case 3.0:  // which postfix?

However, there is a way to achieve a consistent conversion behavior:

  switch (e) {
    case { 3.0 }:  // => remove_reference<decltype(f)>::type{ 3.0 }, perfect

So,

>  2. Floating point; // floating point promotion (?)

is not needed.  No conversion rules need to be added to allow
floating point in switch...case.


--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

Lawrence Crowl <crowl@googlers.com> writes:

| On 1/24/13, Zhihao Yuan <lichray@gmail.com> wrote:
| > Hi,
| >
| > When I was reading Imperfect C++, I feel disappointed as same
| > as the author when I found that the following code does no work:
| >
| >   switch(s)
| >   {
| >     case "abc":
| >    ...
| >   }
| >
| > Generally, in `switch(_ie_)`, _ie_ is required to be implicitly
| > convertible to int, and in `case: _e_:`, _e_ should be an const
| > expression.  The latter one is reasonable, but the first one
| > is not.  Since we have `constexpr`, I don't see there is a
| > drawback to relax the first restriction to "a object of a literal type
| > comparable with == but not implicitly convertible to integer, or
| > an object implicitly convertible to integer".
| >
| > With this change and "N3468: User-defined Literals for
| > Standard Library Types",
| > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3468.pdf
| > we will be able to use the nice UDL syntax in `case`!
| >
| > Let's go back to the `case "abc":`.  *One more reason* to
| > give ""s to `string_ref` -- a literal type.
| >
| > Hope we can write
| >
| >   switch(s)
| >   {
| >     case "abc"s:
| >    ...
| >   }
| >
| > one day.
|
| How would this feature result in code that is significantly
| better than a simple if else if else chain?

switch generally makes distinctness or group of conditions clear and
unambiguous.

Series of if-else usually have dependencies and hide dependencies.


   switch (s->name()) {
      case "warning" : return lot_of_smoke_but_no_fire();
      case "error" : return looks_especially_bad(s);
      case "serious" : return looks_serious(s);
      default : return hardly_worth_mentioning();
   }

--
Gabriel Dos Reis, http://www.axiomatics.org/~gdr/

--

---
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/?hl=en.



.

Lawrence Crowl <crowl@googlers.com> writes:

| On 1/24/13, Zhihao Yuan <lichray@gmail.com> wrote:
| > On Jan 24, 2013 Lawrence Crowl <crowl@googlers.com> wrote:
| > > How would this feature result in code that is significantly
| > > better than a simple if else if else chain?
| >
| > 1. Syntax matters.  SYNTAX MATTERS.
|
| Agreed.  However, the benefit of new syntax must be weighed against
| its cost.  I'm asking you to explain why you think the benefit
| is significant.

He is not proposing a new syntax.
I think he is talking about lifting a semantics restriction, that
currently has a work-around that obscures the intent.

--
Gabriel Dos Reis, http://www.axiomatics.org/~gdr/

--

---
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/?hl=en.



.

--f46d0401678fadbca204d47c298c
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 29, 2013 at 9:18 AM, Gabriel Dos Reis <gdr@axiomatics.org>wrote:

> He is not proposing a new syntax.
>

A tiny new syntax is required: { uniform initialization } in the
`case` labels.


> I think he is talking about lifting a semantics restriction, that
> currently has a work-around that obscures the intent.
>

Not quite.  The semantics of the `switch` statement is still "label
matching", which is unchanged; an allowed user-defined literal
type must provide a constexpr operator== to ensure the "matching"
powered by "comparing" contains no side-effect.

Since the proposed change is minimal, a wording is under construction.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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/?hl=en.



--f46d0401678fadbca204d47c298c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Jan 29, 2013 at 9:18 AM, Gabriel Dos Reis <span di=
r=3D"ltr">&lt;<a href=3D"mailto:gdr@axiomatics.org" target=3D"_blank">gdr@a=
xiomatics.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">He is not proposing a new syntax.<br></block=
quote><div><br></div><div>A tiny new syntax is required: { uniform initiali=
zation } in the<br>
`case` labels.<br></div><div>=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think he is talking about lifting a semantics restriction, that<br>
currently has a work-around that obscures the intent.<br></blockquote><div>=
<br></div><div>Not quite.=A0 The semantics of the `switch` statement is sti=
ll &quot;label<br>matching&quot;, which is unchanged; an allowed user-defin=
ed literal<br>
</div><div>type must provide a constexpr operator=3D=3D to ensure the &quot=
;matching&quot;<br>powered by &quot;comparing&quot; contains no side-effect=
..<br><br></div><div>Since the proposed change is minimal, a wording is unde=
r construction.<br>
</div></div><br>-- <br>Zhihao Yuan, ID lichray<br>The best way to predict t=
he future is to invent it.<br>_____________________________________________=
______<br>4BSD -- <a href=3D"http://4bsd.biz/" target=3D"_blank">http://4bs=
d.biz/</a>
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--f46d0401678fadbca204d47c298c--

.

Zhihao Yuan <lichray@gmail.com> writes:

| On Tue, Jan 29, 2013 at 9:18 AM, Gabriel Dos Reis <gdr@axiomatics.org> wr=
ote:
|=20
|     He is not proposing a new syntax.
|=20
|=20
| A tiny new syntax is required: { uniform initialization } in the
| `case` labels.

???

| =A0
|=20
|     I think he is talking about lifting a semantics restriction, that
|     currently has a work-around that obscures the intent.
|=20
|=20
| Not quite.=A0 The semantics of the `switch` statement is still "label
| matching", which is unchanged; an allowed user-defined literal
| type must provide a constexpr operator=3D=3D to ensure the "matching"
| powered by "comparing" contains no side-effect.

That is semantics; now syntax.

|=20
| Since the proposed change is minimal, a wording is under construction.
|=20
| --
| Zhihao Yuan, ID lichray
| The best way to predict the future is to invent it.
| ___________________________________________________
| 4BSD -- http://4bsd.biz/
|=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=
 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-propo=
sals/?
| hl=3Den.
| =20
| =20

--=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/?hl=3Den.



.

On 30 January 2013 14:08, Gabriel Dos Reis <gdr@axiomatics.org> wrote:
> | Not quite.  The semantics of the `switch` statement is still "label
> | matching", which is unchanged; an allowed user-defined literal
> | type must provide a constexpr operator== to ensure the "matching"
> | powered by "comparing" contains no side-effect.
> That is semantics; now syntax.

This would seem related to
http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3413.html.
I'd expect it to be a small stretch to get literal types to work as
case labels if we can get them
to work as non-type template parameters.

--

---
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/?hl=en.



.

Ville Voutilainen <ville.voutilainen@gmail.com> writes:

| On 30 January 2013 14:08, Gabriel Dos Reis <gdr@axiomatics.org> wrote:
| > | Not quite.  The semantics of the `switch` statement is still "label
| > | matching", which is unchanged; an allowed user-defined literal
| > | type must provide a constexpr operator== to ensure the "matching"
| > | powered by "comparing" contains no side-effect.
| > That is semantics; now syntax.
|
| This would seem related to
| http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3413.html.
| I'd expect it to be a small stretch to get literal types to work as
| case labels if we can get them
| to work as non-type template parameters.

Yes, that is what has been in the back of my mind.
There is a little complication that we need to impose a constraint
on how the scrutinee is matched at runtime in order to allow for
"acceptable" switch-like performance (at most log n)

--

---
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/?hl=en.



.

On Wed, Jan 30, 2013 at 6:20 AM, Gabriel Dos Reis <gdr@axiomatics.org> wrote:
> There is a little complication that we need to impose a constraint
> on how the scrutinee is matched at runtime in order to allow for
> "acceptable" switch-like performance (at most log n)

My proposal does not face the implementation problem in N3413,
and the runtime performance is not my focus.

The option #2 in N3413 is nonsense, since it makes every
`string_ref` to be identical.  The author's attitude really shocked
me.


--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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/?hl=en.



.

Zhihao Yuan <lichray@gmail.com> writes:

| On Wed, Jan 30, 2013 at 6:20 AM, Gabriel Dos Reis <gdr@axiomatics.org> wrote:
| > There is a little complication that we need to impose a constraint
| > on how the scrutinee is matched at runtime in order to allow for
| > "acceptable" switch-like performance (at most log n)
|
| My proposal does not face the implementation problem in N3413,
| and the runtime performance is not my focus.

I do not have data on the success rate of C++ proposals that dismiss
performance concerns from the outset; but I would suspect that would add
another level of skepticism.

--

---
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/?hl=en.



.

On Thu, Jan 31, 2013 at 2:53 AM, Gabriel Dos Reis <gdr@axiomatics.org> wrote:
> I do not have data on the success rate of C++ proposals that dismiss
> performance concerns from the outset; but I would suspect that would add
> another level of skepticism.

This is not a "dismiss".  The correct run-time behavior of a relaxed
switch statement relies on a user-defined operator==, which can
not be optimized to be faster than an if...else chain.  Performance
is important of course, but without a correct semantics all others
are nonsense.


--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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/?hl=en.



.

Zhihao Yuan <lichray@gmail.com> writes:

| On Thu, Jan 31, 2013 at 2:53 AM, Gabriel Dos Reis <gdr@axiomatics.org> wrote:
| > I do not have data on the success rate of C++ proposals that dismiss
| > performance concerns from the outset; but I would suspect that would add
| > another level of skepticism.
|
| This is not a "dismiss".  The correct run-time behavior of a relaxed
| switch statement relies on a user-defined operator==, which can
| not be optimized to be faster than an if...else chain.  Performance
| is important of course, but without a correct semantics all others
| are nonsense.

dismissal of concerns under the pretense of "nonsense."

If I use std::find or std::binary_search, I expect certain algorithmic
complexities even if the behaviour depends on 'operator==' or 'operator<'
which might be user-defined.  There is nothing nonsensical there.

Similarly I would expect a certain algorithmic complexity if the
semantics constraints on switch are relaxed.

Good luck with your proposal.

--

---
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/?hl=en.



.

On Thu, Jan 31, 2013 at 3:53 AM, Gabriel Dos Reis <gdr@axiomatics.org> wrote:
> If I use std::find or std::binary_search, I expect certain algorithmic
> complexities even if the behaviour depends on 'operator==' or 'operator<'
> which might be user-defined.  There is nothing nonsensical there.

Sorry... I guess you were talking about the binary comparison suggested
by N3413.

Yes, this optimization is OK, since the `case` labels are still able
to be selected in any order at runtime with my proposal.

Thanks for your idea.  But we don't need to mention such an
optimization in the wording, I suppose?


--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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/?hl=en.



.

On Thu, Jan 31, 2013 at 4:05 AM, Zhihao Yuan <lichray@gmail.com> wrote:
> But we don't need to mention such an
> optimization in the wording, I suppose?

We have to mention it, because at compile-time we can only check
the strict week ordering of the `case` labels, but it is unknown
that the an expr in `switch (expr)` still meets the requirements or
not.  Fail to establish such an relationship at runtime is now an UB.

The updated proposal is at:
http://students.cs.niu.edu/~z1565938/switch.html

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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/?hl=en.



.

On 01/30/2013 01:17 PM, Ville Voutilainen wrote:
> On 30 January 2013 14:08, Gabriel Dos Reis <gdr@axiomatics.org> wrote:
>> | Not quite.  The semantics of the `switch` statement is still "label
>> | matching", which is unchanged; an allowed user-defined literal
>> | type must provide a constexpr operator== to ensure the "matching"
>> | powered by "comparing" contains no side-effect.
>> That is semantics; now syntax.
>
> This would seem related to
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3413.html.
> I'd expect it to be a small stretch to get literal types to work as
> case labels if we can get them
> to work as non-type template parameters.

I'd hope the "switch" case is actually easier, because it doesn't
interact with the linker at all.

But it would be nice if the requirements for a type usable in an
extended switch would be the same as those for non-type template
parameters.

Jens

--

---
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/?hl=en.



.

Jens Maurer <Jens.Maurer@gmx.net> writes:

| On 01/30/2013 01:17 PM, Ville Voutilainen wrote:
| > On 30 January 2013 14:08, Gabriel Dos Reis <gdr@axiomatics.org> wrote:
| >> | Not quite.  The semantics of the `switch` statement is still "label
| >> | matching", which is unchanged; an allowed user-defined literal
| >> | type must provide a constexpr operator== to ensure the "matching"
| >> | powered by "comparing" contains no side-effect.
| >> That is semantics; now syntax.
| >
| > This would seem related to
| > http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3413.html.
| > I'd expect it to be a small stretch to get literal types to work as
| > case labels if we can get them
| > to work as non-type template parameters.
|
| I'd hope the "switch" case is actually easier, because it doesn't
| interact with the linker at all.
|
| But it would be nice if the requirements for a type usable in an
| extended switch would be the same as those for non-type template
| parameters.

Yes.  We should aim for retaining standard switch performance where
possible even in the face of user abstraction.  E.g., if I wrap an 'int'
in a class and provides the appropriate comparison (hashing too?)
functions, and use the class instead of 'int', I would like to get the
same performance.

--

---
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/?hl=en.



.