------=_Part_247_872309312.1483659128826
Content-Type: multipart/alternative;
 boundary="----=_Part_248_669795502.1483659128826"

------=_Part_248_669795502.1483659128826
Content-Type: text/plain; charset=UTF-8

Hi all

I'd like to revisit the C++ switch statement debate again.

I am thinking this so far:

(Note This is not a proposal to modify the existing switch statement in any
way as yet.)

switch v2
---------

// switch v2 example:

switch (x) // Supports the new (e; x) too of course.
case a:
  for ( a: c )
    if (whatever)
        switch break;
case b:
    switch (y)
    case 1:
    case 2:
    case 3:
    switch;
case c:
    whatever();
default:
    whatever_else();

switch;

// end example.


Changes from classic switch:
* The new switch begins with no brace. This ditinquishes it from the
classic switch.
* switch ends with a switch; statement.
* case/default blocks breaks automatically at the next
case:/default:/switch;
* case opens a scope always.
* switch break leaves a case/default block; break would be a syntax error
if not in a loop.

My main issues with the current switch which I hope these changes address
are:

* I hate trying to format switches. I'd like less nesting and brace
ambiguity and formatting concerns here.
  Win32 window message handling functions are a great example of what I
want to make cleaner.
* I really hate not having a scope available by default and getting an
error.
  Then fixing the error and begin juggling yet more braces.

* I find switch verbose.

* break is not usually the default I want.


Questions:


1. Would this new syntax create any obvious parsing issues that would make
it a no go.
   I'm talking about the minimum in the example.

2. I'd like to support case (10,20,30): With an 'if any of these' meaning.
Is that syntax going to work or must a new syntax be invented here too.
If new, suggestion welcome.

3. I am mulling allow fallthrough as a keyword. But perhaps just insist on
goto regular label?
   Opinions on this please.

4. I'm also keen to narrow down what if anything can exist in a switch but
outside of a case/default block.
I believe attributes and labels are necessary but probably no more.


Thanks


--
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/c4d4e58a-a718-4211-ac17-91f1671bf57f%40isocpp.org.

------=_Part_248_669795502.1483659128826
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi all</div><div><br></div><div>I&#39;d=C2=A0like=C2=
=A0to revisit the C++ switch statement debate again.</div><div><br></div><d=
iv>I am thinking this so far:</div><div><br></div><div>(Note This is not a =
proposal to modify the existing switch statement in any way as yet.)</div><=
div><br></div><p>switch v2<br>---------</p><p>// switch v2 example:</p><p>s=
witch (x) // Supports the new (e; x) too of course.</p><div>case a:<br>=C2=
=A0 for ( a: c )<br>=C2=A0=C2=A0=C2=A0 if (whatever)<br>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 switch break;<br>case b:<br>=C2=A0=C2=A0=C2=A0 swi=
tch (y)<br>=C2=A0=C2=A0=C2=A0 case 1:<br>=C2=A0=C2=A0=C2=A0 case 2:<br>=C2=
=A0=C2=A0 =C2=A0case 3:<br>=C2=A0=C2=A0=C2=A0 switch;<br>case c:</div><div>=
=C2=A0=C2=A0=C2=A0 whatever();</div><div>default:</div><div>=C2=A0=C2=A0=C2=
=A0 whatever_else();</div><p>switch;</p><p>// end example.</p><p><br>Change=
s from classic switch:</p><div>* The new switch begins with no brace. This =
ditinquishes it from the classic switch.<br>* switch ends with a switch; st=
atement.<br>* case/default blocks breaks automatically at the next case:/de=
fault:/switch;<br>* case opens a scope always.<br>* switch break leaves a c=
ase/default block; break would be a syntax error if not in a loop.</div><di=
v><br></div><p>My main issues with the current switch which I hope=C2=A0the=
se changes=C2=A0address are:</p><p>* I=C2=A0hate trying to format switches.=
=C2=A0I&#39;d like=C2=A0less nesting and brace ambiguity and formatting con=
cerns here.<br>=C2=A0 Win32 window message handling functions are a great e=
xample of what I want to make cleaner.</p><div>* I really hate not having a=
 scope available by default and getting an error.<br>=C2=A0 Then fixing the=
 error and begin juggling yet more braces.</div><div><p>* I find switch ver=
bose.</p><p>* break is not usually the default I want.</p><p><br></p><p>Que=
stions:</p><p><br></p><p>1. Would this new syntax create any obvious parsin=
g issues that would make it a no go.<br>=C2=A0=C2=A0 I&#39;m talking about =
the minimum in the example.</p><p>2. I&#39;d like to support case (10,20,30=
): With an &#39;if any of these&#39; meaning.<br>Is that syntax going to wo=
rk or must a new syntax be invented here too.<br>If new, suggestion welcome=
..</p><p>3. I am mulling allow fallthrough as a keyword. But perhaps just in=
sist on goto regular label?<br>=C2=A0=C2=A0 Opinions on this please.</p><p>=
4. I&#39;m also keen to narrow down what if anything can exist in a switch =
but outside of a case/default block.<br>I believe attributes and labels are=
 necessary but probably no more.</p><p><br></p><p>Thanks</p></div><div><br>=
</div><div><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c4d4e58a-a718-4211-ac17-91f1671bf57f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c4d4e58a-a718-4211-ac17-91f1671bf57f=
%40isocpp.org</a>.<br />

------=_Part_248_669795502.1483659128826--

------=_Part_247_872309312.1483659128826--

.

--94eb2c074a0476f99b054568ea04
Content-Type: text/plain; charset=UTF-8

Personally, I don't like the braceless approach, and much less the use of
"switch" to open it and "switch;" to close it.

Plus, break-by-default would, erm, break, lots of existing code. I don't
have enough sympathy for people who don't break when they should to make
this kind of change.

"switch break" is a nice concept but if anything should be "break switch"
or some more intuitive syntax.

--
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/CACGiwhEos3aSXTHpb3Nq0iBJZ1DYeyvagjfFLzx3xOjMsVEM8w%40mail.gmail.com.

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

<div dir=3D"ltr"><div><div>Personally, I don&#39;t like the braceless appro=
ach, and much less the use of &quot;switch&quot; to open it and &quot;switc=
h;&quot; to close it.<br><br></div>Plus, break-by-default would, erm, break=
, lots of existing code. I don&#39;t have enough sympathy for people who do=
n&#39;t break when they should to make this kind of change.<br><br></div>&q=
uot;switch break&quot; is a nice concept but if anything should be &quot;br=
eak switch&quot; or some more intuitive syntax.<br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhEos3aSXTHpb3Nq0iBJZ1DYeyvagjfF=
Lzx3xOjMsVEM8w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhEos3aSXTHp=
b3Nq0iBJZ1DYeyvagjfFLzx3xOjMsVEM8w%40mail.gmail.com</a>.<br />

--94eb2c074a0476f99b054568ea04--

.

On Thu, Jan 05, 2017 at 03:32:08PM -0800, gmisocpp@gmail.com wrote:
> Hi all
>
> I'd like to revisit the C++ switch statement debate again.
>
> I am thinking this so far:
>
> (Note This is not a proposal to modify the existing switch statement in any
> way as yet.)
>
> switch v2
> ---------
>
> // switch v2 example:
>
> switch (x) // Supports the new (e; x) too of course.
> case a:
>   for ( a: c )
>     if (whatever)
>         switch break;
> case b:
>     switch (y)
>     case 1:
>     case 2:
>     case 3:
>     switch;
> case c:
>     whatever();
> default:
>     whatever_else();
>
> switch;
>
> // end example.
>
>
> Changes from classic switch:
> * The new switch begins with no brace. This ditinquishes it from the
> classic switch.

There is no requirement of braces in a classic switch.

> * switch ends with a switch; statement.

This would break my code. I am using

#define FOO switch (0) default: type name

rather than the more common

#define FOO if (false) ; else type name

when I need to declare an open scope in order to explain to compilers that I
haven't messed up my else nesting.

Please ensure that open scopes are preserved.

> 1. Would this new syntax create any obvious parsing issues that would make
> it a no go.

Yes. There is no requirement of braces in a switch statement,

/MF

--
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/20170106084340.GA26696%40noemi.

.

------=_Part_780_448810779.1483701022114
Content-Type: multipart/alternative;
 boundary="----=_Part_781_2010620599.1483701022114"

------=_Part_781_2010620599.1483701022114
Content-Type: text/plain; charset=UTF-8



On Friday, January 6, 2017 at 9:36:38 PM UTC+13, D. B. wrote:
>
> Personally, I don't like the braceless approach, and much less the use of
> "switch" to open it and "switch;" to close it.
>
> Plus, break-by-default would, erm, break, lots of existing code. I don't
> have enough sympathy for people who don't break when they should to make
> this kind of change.
>
> "switch break" is a nice concept but if anything should be "break switch"
> or some more intuitive syntax.
>

Sorry I meant "break switch" to be the proposed means to exit. That was an
unfortunately typo.
break case is possibly another option.

I'm keen to be rid of braces opening switches though as I think that's the
root of my formatting and nesting dislike.
I also think that switches tend to be quite long so looking at a closing
brace on switch offers no surety what it is.
Closing with switch; would fix that. It's unusual for C++ but I think we'd
get use to it.

I'd probably vote for the space for namespaces too. i.e.:
namespace zen: // open
//whatever
namespace zen; // close

Any takers?


--
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/63135e5f-ddb0-41e2-96ca-7435762f9ced%40isocpp.org.

------=_Part_781_2010620599.1483701022114
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, January 6, 2017 at 9:36:38 PM UTC+13, D=
.. B. wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0=
..8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left=
-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><div>Personal=
ly, I don&#39;t like the braceless approach, and much less the use of &quot=
;switch&quot; to open it and &quot;switch;&quot; to close it.<br><br></div>=
Plus, break-by-default would, erm, break, lots of existing code. I don&#39;=
t have enough sympathy for people who don&#39;t break when they should to m=
ake this kind of change.<br><br></div>&quot;switch break&quot; is a nice co=
ncept but if anything should be &quot;break switch&quot; or some more intui=
tive syntax.<br></div></blockquote><div><br></div><div>Sorry I meant &quot;=
break switch&quot;=C2=A0to be the proposed means to exit. That was an unfor=
tunately typo.</div><div>break case is possibly another option.</div><div><=
br></div><div>I&#39;m keen to be rid of=C2=A0braces opening switches though=
 as I think that&#39;s the root of my formatting and nesting dislike.</div>=
<div>I also think that switches tend=C2=A0to be quite long so looking at=C2=
=A0a closing brace on=C2=A0switch offers no surety what it is.</div><div>Cl=
osing with switch; would fix that. It&#39;s unusual for C++ but I think we&=
#39;d get use to it.</div><div><br></div><div>I&#39;d probably vote for the=
 space for namespaces too. i.e.:</div><div>namespace zen: // open</div><div=
>//whatever</div><div>namespace zen; // close</div><div><br></div><div>Any =
takers?</div><div><br></div><div><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/63135e5f-ddb0-41e2-96ca-7435762f9ced%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/63135e5f-ddb0-41e2-96ca-7435762f9ced=
%40isocpp.org</a>.<br />

------=_Part_781_2010620599.1483701022114--

------=_Part_780_448810779.1483701022114--

.

------=_Part_640_328289886.1483701147165
Content-Type: multipart/alternative;
 boundary="----=_Part_641_236548102.1483701147165"

------=_Part_641_236548102.1483701147165
Content-Type: text/plain; charset=UTF-8



On Friday, January 6, 2017 at 9:43:44 PM UTC+13, Magnus Fromreide wrote:
>
> On Thu, Jan 05, 2017 at 03:32:08PM -0800, gmis...@gmail.com <javascript:>
> wrote:
> > Hi all
> >
> > I'd like to revisit the C++ switch statement debate again.
> >
> > I am thinking this so far:
> >
> > (Note This is not a proposal to modify the existing switch statement in
> any
> > way as yet.)
> >
> > switch v2
> > ---------
> >
> > // switch v2 example:
> >
> > switch (x) // Supports the new (e; x) too of course.
> > case a:
> >   for ( a: c )
> >     if (whatever)
> >         switch break;
> > case b:
> >     switch (y)
> >     case 1:
> >     case 2:
> >     case 3:
> >     switch;
> > case c:
> >     whatever();
> > default:
> >     whatever_else();
> >
> > switch;
> >
> > // end example.
> >
> >
> > Changes from classic switch:
> > * The new switch begins with no brace. This ditinquishes it from the
> > classic switch.
>
> There is no requirement of braces in a classic switch.
>
> > * switch ends with a switch; statement.
>
> This would break my code. I am using
>
> #define FOO switch (0) default: type name
>
> rather than the more common
>
> #define FOO if (false) ; else type name
>
> when I need to declare an open scope in order to explain to compilers that
> I
> haven't messed up my else nesting.
>
> Please ensure that open scopes are preserved.
>
> > 1. Would this new syntax create any obvious parsing issues that would
> make
> > it a no go.
>
> Yes. There is no requirement of braces in a switch statement,
>
> /MF
>

If pains me to care about that, but if we must, then changing the proposal
to switch break (x) to open a switch
would seem to fix your issue? I'd be ok with that. Would you?

--
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/45b8e63b-8808-429d-8cae-1cb4e2ce85c3%40isocpp.org.

------=_Part_641_236548102.1483701147165
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, January 6, 2017 at 9:43:44 PM UTC+13, M=
agnus Fromreide wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); =
border-left-width: 1px; border-left-style: solid;">On Thu, Jan 05, 2017 at =
03:32:08PM -0800, <a onmousedown=3D"this.href=3D&#39;javascript:&#39;;retur=
n true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D=
"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"D=
Ln7x_hKDAAJ">gmis...@gmail.com</a> wrote:
<br>&gt; Hi all
<br>&gt;=20
<br>&gt; I&#39;d like to revisit the C++ switch statement debate again.
<br>&gt;=20
<br>&gt; I am thinking this so far:
<br>&gt;=20
<br>&gt; (Note This is not a proposal to modify the existing switch stateme=
nt in any=20
<br>&gt; way as yet.)
<br>&gt;=20
<br>&gt; switch v2
<br>&gt; ---------
<br>&gt;=20
<br>&gt; // switch v2 example:
<br>&gt;=20
<br>&gt; switch (x) // Supports the new (e; x) too of course.
<br>&gt; case a:
<br>&gt; =C2=A0 for ( a: c )
<br>&gt; =C2=A0 =C2=A0 if (whatever)
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 switch break;
<br>&gt; case b:
<br>&gt; =C2=A0 =C2=A0 switch (y)
<br>&gt; =C2=A0 =C2=A0 case 1:
<br>&gt; =C2=A0 =C2=A0 case 2:
<br>&gt; =C2=A0 =C2=A0 case 3:
<br>&gt; =C2=A0 =C2=A0 switch;
<br>&gt; case c:
<br>&gt; =C2=A0 =C2=A0 whatever();
<br>&gt; default:
<br>&gt; =C2=A0 =C2=A0 whatever_else();
<br>&gt;=20
<br>&gt; switch;
<br>&gt;=20
<br>&gt; // end example.
<br>&gt;=20
<br>&gt;=20
<br>&gt; Changes from classic switch:
<br>&gt; * The new switch begins with no brace. This ditinquishes it from t=
he=20
<br>&gt; classic switch.
<br>
<br>There is no requirement of braces in a classic switch.
<br>
<br>&gt; * switch ends with a switch; statement.
<br>
<br>This would break my code. I am using
<br>
<br>#define FOO switch (0) default: type name
<br>
<br>rather than the more common
<br>
<br>#define FOO if (false) ; else type name
<br>
<br>when I need to declare an open scope in order to explain to compilers t=
hat I
<br>haven&#39;t messed up my else nesting.
<br>
<br>Please ensure that open scopes are preserved.
<br>
<br>&gt; 1. Would this new syntax create any obvious parsing issues that wo=
uld make=20
<br>&gt; it a no go.
<br>
<br>Yes. There is no requirement of braces in a switch statement,
<br>
<br>/MF
<br></blockquote><div><br></div><div>If pains me to care about that, but if=
 we must, then=C2=A0changing the proposal to switch break (x) to open a swi=
tch</div><div>would seem to fix your issue? I&#39;d be ok with that. Would =
you?</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/45b8e63b-8808-429d-8cae-1cb4e2ce85c3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/45b8e63b-8808-429d-8cae-1cb4e2ce85c3=
%40isocpp.org</a>.<br />

------=_Part_641_236548102.1483701147165--

------=_Part_640_328289886.1483701147165--

.

--94eb2c074a0447f40b05456b634d
Content-Type: text/plain; charset=UTF-8

On Fri, Jan 6, 2017 at 11:10 AM, <gmisocpp@gmail.com> wrote:

>
> I'm keen to be rid of braces opening switches though as I think that's the
> root of my formatting and nesting dislike.
> I also think that switches tend to be quite long so looking at a closing
> brace on switch offers no surety what it is.
> Closing with switch; would fix that. It's unusual for C++ but I think we'd
> get use to it.
>
> I'd probably vote for the space for namespaces too. i.e.:
> namespace zen: // open
> //whatever
> namespace zen; // close
>
> Any takers?
>

Yikes. That doesn't help readability at all. Code that requires a comment
to know what it's doing should be avoided, not enshrined in the language's
syntax - even if it's not code whose purpose differs, and differs exactly
oppositely, depending on where it is and whether it was already written
previously.

--
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/CACGiwhE15jB1h9PiAUEy2n8ZACuH6_G3ix%3DsKr6XynMPnyzxbA%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Jan 6, 2017 at 11:10 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:gmiso=
cpp@gmail.com" target=3D"_blank">gmisocpp@gmail.com</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div>I&#39;m keen to =
be rid of=C2=A0braces opening switches though as I think that&#39;s the roo=
t of my formatting and nesting dislike.</div><div>I also think that switche=
s tend=C2=A0to be quite long so looking at=C2=A0a closing brace on=C2=A0swi=
tch offers no surety what it is.</div><div>Closing with switch; would fix t=
hat. It&#39;s unusual for C++ but I think we&#39;d get use to it.</div><div=
><br></div><div>I&#39;d probably vote for the space for namespaces too. i.e=
..:</div><div>namespace zen: // open</div><div>//whatever</div><div>namespac=
e zen; // close</div><div><br></div><div>Any takers?</div></div></blockquot=
e><div><br></div><div>Yikes. That doesn&#39;t help readability at all. Code=
 that requires a comment to know what it&#39;s doing should be avoided, not=
 enshrined in the language&#39;s syntax - even if it&#39;s not code whose p=
urpose differs, and differs exactly oppositely, depending on where it is an=
d whether it was already written previously.<br>=C2=A0<br></div></div></div=
></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhE15jB1h9PiAUEy2n8ZACuH6_G3ix%3=
DsKr6XynMPnyzxbA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhE15jB1h9=
PiAUEy2n8ZACuH6_G3ix%3DsKr6XynMPnyzxbA%40mail.gmail.com</a>.<br />

--94eb2c074a0447f40b05456b634d--

.

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

....I just noticed the subtle difference, in that the opening declaration
ends with a colon, and the closing with a semicolon. However, I think that
might even support the point I was trying to make ;-)

--
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/CACGiwhGdOZ5D_aEv3jh5XtE4-9DbCsOA%3DiHqj-nRoMCE-6CtpA%40mail.gmail.com.

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

<div dir=3D"ltr">...I just noticed the subtle difference, in that the openi=
ng declaration ends with a colon, and the closing with a semicolon. However=
, I think that might even support the point I was trying to make ;-)<br></d=
iv>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhGdOZ5D_aEv3jh5XtE4-9DbCsOA%3Di=
Hqj-nRoMCE-6CtpA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhGdOZ5D_a=
Ev3jh5XtE4-9DbCsOA%3DiHqj-nRoMCE-6CtpA%40mail.gmail.com</a>.<br />

--f403045eaca894a94805456b7a07--

.

------=_Part_825_444535206.1483702861620
Content-Type: multipart/alternative;
 boundary="----=_Part_826_2025786032.1483702861621"

------=_Part_826_2025786032.1483702861621
Content-Type: text/plain; charset=UTF-8


On Saturday, January 7, 2017 at 12:33:35 AM UTC+13, D. B. wrote:
>
> On Fri, Jan 6, 2017 at 11:10 AM, <gmis...@gmail.com <javascript:>> wrote:
>
>>
>> I'm keen to be rid of braces opening switches though as I think that's
>> the root of my formatting and nesting dislike.
>> I also think that switches tend to be quite long so looking at a closing
>> brace on switch offers no surety what it is.
>> Closing with switch; would fix that. It's unusual for C++ but I think
>> we'd get use to it.
>>
>> I'd probably vote for the space for namespaces too. i.e.:
>> namespace zen: // open
>> //whatever
>> namespace zen; // close
>>
>> Any takers?
>>
>
> Yikes. That doesn't help readability at all. Code that requires a comment
> to know what it's doing should be avoided, not enshrined in the language's
> syntax - even if it's not code whose purpose differs, and differs exactly
> oppositely, depending on where it is and whether it was already written
> previously.
>

Sorry I don't get where you are coming from here?
Most code that I see looks like this:

namespace zen {

} // zen

Which I dislike because people update the first zend and forget the second
zen in the comment.
Same thing happens in include guards. #endif //whatever

What I suggested was to get rid of that and make it this:
namespace zen:
// Long stuff here, above line opens, below line closes, compiler checks it
matches.
namespace zen;

So we are already using comments to make code clear and the comments get
out of step.
My suggestion would seem to fix that?

So what don't you like about that again please?


>

--
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/d218bd24-b622-4660-ab9a-e34106360178%40isocpp.org.

------=_Part_826_2025786032.1483702861621
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Saturday, January 7, 2017 at 12:33:35 AM UTC+13, D.=
 B. wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.=
8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-=
width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><div class=3D"=
gmail_quote">On Fri, Jan 6, 2017 at 11:10 AM,  <span dir=3D"ltr">&lt;<a onm=
ousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this=
..href=3D&#39;javascript:&#39;;return true;" href=3D"javascript:" target=3D"=
_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"Ba2pqD1UDAAJ">gmis...@gma=
il.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 2=
04, 204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"lt=
r"><br><div>I&#39;m keen to be rid of=C2=A0braces opening switches though a=
s I think that&#39;s the root of my formatting and nesting dislike.</div><d=
iv>I also think that switches tend=C2=A0to be quite long so looking at=C2=
=A0a closing brace on=C2=A0switch offers no surety what it is.</div><div>Cl=
osing with switch; would fix that. It&#39;s unusual for C++ but I think we&=
#39;d get use to it.</div><div><br></div><div>I&#39;d probably vote for the=
 space for namespaces too. i.e.:</div><div>namespace zen: // open</div><div=
>//whatever</div><div>namespace zen; // close</div><div><br></div><div>Any =
takers?</div></div></blockquote><div><br></div><div>Yikes. That doesn&#39;t=
 help readability at all. Code that requires a comment to know what it&#39;=
s doing should be avoided, not enshrined in the language&#39;s syntax - eve=
n if it&#39;s not code whose purpose differs, and differs exactly oppositel=
y, depending on where it is and whether it was already written previously.<=
br></div></div></div></div></blockquote><div><br></div><div>Sorry I don&#39=
;t get where you are coming from here?</div><div>Most code that I see looks=
 like this:</div><div><br></div><div>namespace=C2=A0zen {</div><div><br></d=
iv><div>} // zen</div><div><br></div><div>Which I dislike because people up=
date the first=C2=A0zend and forget the second zen in the comment.</div><di=
v>Same=C2=A0thing happens in=C2=A0include guards. #endif //whatever</div><d=
iv><br></div><div>What I=C2=A0suggested was to get rid of that and make it =
this:</div><div>namespace zen:</div><div>// Long stuff here, above line ope=
ns, below line closes, compiler checks it matches.</div><div>namespace zen;=
</div><div><br></div><div>So we are already using comments to make code cle=
ar and the comments get out of step.</div><div>My suggestion would seem to =
fix that?</div><div><br></div><div>So what don&#39;t you like about that ag=
ain please?</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 2=
04, 204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"lt=
r"><div><div class=3D"gmail_quote"><div>=C2=A0<br></div></div></div></div>
</blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d218bd24-b622-4660-ab9a-e34106360178%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d218bd24-b622-4660-ab9a-e34106360178=
%40isocpp.org</a>.<br />

------=_Part_826_2025786032.1483702861621--

------=_Part_825_444535206.1483702861620--

.

------=_Part_457_1079750135.1483702923509
Content-Type: multipart/alternative;
 boundary="----=_Part_458_1618428558.1483702923509"

------=_Part_458_1618428558.1483702923509
Content-Type: text/plain; charset=UTF-8



On Saturday, January 7, 2017 at 12:40:06 AM UTC+13, D. B. wrote:
>
> ...I just noticed the subtle difference, in that the opening declaration
> ends with a colon, and the closing with a semicolon. However, I think that
> might even support the point I was trying to make ;-)
>

I think not -)

--
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/3815fa02-2b3c-4885-99c3-02c99bda7444%40isocpp.org.

------=_Part_458_1618428558.1483702923509
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, January 7, 2017 at 12:40:06 AM UTC+13=
, D. B. wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0p=
x 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-l=
eft-width: 1px; border-left-style: solid;"><div dir=3D"ltr">...I just notic=
ed the subtle difference, in that the opening declaration ends with a colon=
, and the closing with a semicolon. However, I think that might even suppor=
t the point I was trying to make ;-)<br></div></blockquote><div><br></div><=
div>I think not=C2=A0-)=C2=A0</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3815fa02-2b3c-4885-99c3-02c99bda7444%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3815fa02-2b3c-4885-99c3-02c99bda7444=
%40isocpp.org</a>.<br />

------=_Part_458_1618428558.1483702923509--

------=_Part_457_1079750135.1483702923509--

.

------=_Part_488_2029777664.1483703356025
Content-Type: multipart/alternative;
 boundary="----=_Part_489_1119822633.1483703356025"

------=_Part_489_1119822633.1483703356025
Content-Type: text/plain; charset=UTF-8



On Saturday, January 7, 2017 at 12:40:06 AM UTC+13, D. B. wrote:
>
> ...I just noticed the subtle difference, in that the opening declaration
> ends with a colon, and the closing with a semicolon. However, I think that
> might even support the point I was trying to make ;-)
>

Just to really bug you, we could also do:

module m:
void whatever {};
module m;

ha ha :)

--
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/743d8863-19ba-4ea3-b5c8-42baccde605d%40isocpp.org.

------=_Part_489_1119822633.1483703356025
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, January 7, 2017 at 12:40:06 AM UTC+13=
, D. B. wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0p=
x 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-l=
eft-width: 1px; border-left-style: solid;"><div dir=3D"ltr">...I just notic=
ed the subtle difference, in that the opening declaration ends with a colon=
, and the closing with a semicolon. However, I think that might even suppor=
t the point I was trying to make ;-)<br></div></blockquote><div><br></div><=
div>Just to really bug you, we could also do:</div><div><br></div><div>modu=
le m:</div><div>void whatever {};</div><div>module=C2=A0m;=C2=A0</div><div>=
<br></div><div>ha ha :)</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/743d8863-19ba-4ea3-b5c8-42baccde605d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/743d8863-19ba-4ea3-b5c8-42baccde605d=
%40isocpp.org</a>.<br />

------=_Part_489_1119822633.1483703356025--

------=_Part_488_2029777664.1483703356025--

.

On Fri, Jan 06, 2017 at 03:12:27AM -0800, gmisocpp@gmail.com wrote:
>
>
> On Friday, January 6, 2017 at 9:43:44 PM UTC+13, Magnus Fromreide wrote:
> >
> > On Thu, Jan 05, 2017 at 03:32:08PM -0800, gmis...@gmail.com <javascript:>
> > wrote:
> > > Hi all
> > >
> > > I'd like to revisit the C++ switch statement debate again.
> > >
> > > I am thinking this so far:
> > >
> > > (Note This is not a proposal to modify the existing switch statement in
> > any
> > > way as yet.)
> > >
> > > switch v2
> > > ---------
> > >
> > > // switch v2 example:
> > >
> > > switch (x) // Supports the new (e; x) too of course.
> > > case a:
> > >   for ( a: c )
> > >     if (whatever)
> > >         switch break;
> > > case b:
> > >     switch (y)
> > >     case 1:
> > >     case 2:
> > >     case 3:
> > >     switch;
> > > case c:
> > >     whatever();
> > > default:
> > >     whatever_else();
> > >
> > > switch;
> > >
> > > // end example.
> > >
> > >
> > > Changes from classic switch:
> > > * The new switch begins with no brace. This ditinquishes it from the
> > > classic switch.
> >
> > There is no requirement of braces in a classic switch.
> >
> > > * switch ends with a switch; statement.
> >
> > This would break my code. I am using
> >
> > #define FOO switch (0) default: type name
> >
> > rather than the more common
> >
> > #define FOO if (false) ; else type name
> >
> > when I need to declare an open scope in order to explain to compilers that
> > I
> > haven't messed up my else nesting.
> >
> > Please ensure that open scopes are preserved.
> >
> > > 1. Would this new syntax create any obvious parsing issues that would
> > make
> > > it a no go.
> >
> > Yes. There is no requirement of braces in a switch statement,
> >
> > /MF
> >
>
> If pains me to care about that, but if we must, then changing the proposal
> to switch break (x) to open a switch
> would seem to fix your issue? I'd be ok with that. Would you?

It would move the proposal out of the breaking change space so I would not be
"over my dead body" about it.

I still predict that you will find it hard to convice the commmitte given that
this looks pretty alien to the rest of C++ and adds very little value.

#define BEGIN MY_SWITCH(...) switch (__VA_ARGS__) {
#define MY_SWITCH_CASE break; case
#define END_MY_SWITCH }

/MF

--
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/20170106115123.GA27846%40noemi.

.

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

On Fri, Jan 6, 2017 at 11:41 AM, <gmisocpp@gmail.com> wrote:

> Sorry I don't get where you are coming from here?
> Most code that I see looks like this:
>
> namespace zen {
>
> } // zen
>
> Which I dislike because people update the first zend and forget the second
> zen in the comment.
> Same thing happens in include guards. #endif //whatever
>
> What I suggested was to get rid of that and make it this:
> namespace zen:
> // Long stuff here, above line opens, below line closes, compiler checks
> it matches.
> namespace zen;
>
> So we are already using comments to make code clear and the comments get
> out of step.
> My suggestion would seem to fix that?
>
> So what don't you like about that again please?
>

I don't like that the opening and closing line look almost identical and
require me to squint at my screen, and ameliorating that means adding
comments, something I can already do with namespace whatever {} //
namespace whatever

That said, I generally find that having to add comments to indicate which
namespace is ending means there's a design issue (in application code
anyway; it's probably different in large libraries, which I don't right)

--
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/CACGiwhFvdXaeegJ%2BcJS%3D45bL%2B8q5-M0gz-P2CbiOLdN%2B57g%3D6g%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Jan 6, 2017 at 11:41 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:gmiso=
cpp@gmail.com" target=3D"_blank">gmisocpp@gmail.com</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div><span class=3D""></span><div>Sorry I =
don&#39;t get where you are coming from here?</div><div>Most code that I se=
e looks like this:</div><div><br></div><div>namespace=C2=A0zen {</div><div>=
<br></div><div>} // zen</div><div><br></div><div>Which I dislike because pe=
ople update the first=C2=A0zend and forget the second zen in the comment.</=
div><div>Same=C2=A0thing happens in=C2=A0include guards. #endif //whatever<=
/div><div><br></div><div>What I=C2=A0suggested was to get rid of that and m=
ake it this:</div><div>namespace zen:</div><div>// Long stuff here, above l=
ine opens, below line closes, compiler checks it matches.</div><div>namespa=
ce zen;</div><div><br></div><div>So we are already using comments to make c=
ode clear and the comments get out of step.</div><div>My suggestion would s=
eem to fix that?</div><div><br></div><div>So what don&#39;t you like about =
that again please?=C2=A0</div></div></blockquote><div><br></div><div>I don&=
#39;t like that the opening and closing line look almost identical and requ=
ire me to squint at my screen, and ameliorating that means adding comments,=
 something I can already do with <span style=3D"font-family:monospace,monos=
pace">namespace whatever {} // namespace whatever<br><br></span></div><div>=
<span style=3D"font-family:monospace,monospace"><font face=3D"arial,helveti=
ca,sans-serif">That said, I generally find that having to add comments to i=
ndicate which namespace is ending means there&#39;s a design issue (in appl=
ication code anyway; it&#39;s probably different in large libraries, which =
I don&#39;t right)<br></font>=C2=A0</span><br></div><div><br></div><div><br=
></div></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhFvdXaeegJ%2BcJS%3D45bL%2B8q5-M=
0gz-P2CbiOLdN%2B57g%3D6g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwh=
FvdXaeegJ%2BcJS%3D45bL%2B8q5-M0gz-P2CbiOLdN%2B57g%3D6g%40mail.gmail.com</a>=
..<br />

--f403045eaca836f93805456baac3--

.

--94eb2c1abc0690c84d05456bc4f3
Content-Type: text/plain; charset=UTF-8

On Fri, Jan 6, 2017 at 12:32 AM, <gmisocpp@gmail.com> wrote:

> * I hate trying to format switches. I'd like less nesting and brace
ambiguity and formatting concerns here.

> * I really hate not having a scope available by default and getting an
error.

> * I find switch verbose.

The above are *nuisances.* They do not *preclude* the use of a switch
statement.

A real* problem* with the existing switch statement is that its conditional
expression must be (essentially) of an integral type, and case labels
compile-time constants. If I want something else, a typical case being
strings, I *cannot use* the switch statement.

In the latter case it might be argued that I could achieve what I want to
by using else if, or potentially better performing (unordered) map lookup.
However, the same could be said about the integral case, yet we have switch
available in that case. So this is at best illogical.

At a more fundamental level, when I use switch, I say to the compiler and
the readers of the program, "I want a selection from a *mutually exclusive*
list of options; please do so *as efficiently as possible*". This is a hint
to the compiler that it is free to use something better than a sequential
scan. For example, a perfect hash table - try implementing that without
compiler support!

Being able to use switch with non-integral types would really make it
switch v2. Just addressing the inconveniences listed above falls way short
of that.

The compile-type constant labels are a somewhat different issue. It is true
that without them being compile-time constant, there is no way to ensure
that the options are mutually exclusive at the compile time, and less
latitude for optimisation. Yet I think this might also be a useful feature,
still more valuable than purely syntactic improvements.

> * break is not usually the default I want.

I do not think I understood you here.

Cheers,
V.

--
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/CAA7YVg1yvEwNO-cKBoHn8qpa2cERK_nSEHUK8YdW8jb54nYNSg%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Jan 6, 2017 at 12:32 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:gmiso=
cpp@gmail.com" target=3D"_blank">gmisocpp@gmail.com</a>&gt;</span> wrote:<b=
r><div><br></div><div>&gt; * I=C2=A0hate trying to format switches.=C2=A0I&=
#39;d like=C2=A0less nesting and brace ambiguity and formatting concerns he=
re.</div><div><br></div><div>&gt; * I really hate not having a scope availa=
ble by default and getting an error.</div><div><br></div><div>&gt; * I find=
 switch verbose.</div><div><br></div><div>The above are <i>nuisances.</i>=
=C2=A0They do not <i>preclude</i> the use of a switch statement.</div><div>=
<br></div><div>A real<i>=C2=A0problem</i>=C2=A0with the existing switch sta=
tement is that its conditional expression must be (essentially) of an integ=
ral type, and case labels compile-time constants. If I want something else,=
 a typical case being strings, I <i>cannot use</i> the switch statement.</d=
iv><div><br></div><div>In the latter case it might be argued that I could a=
chieve what I want to by using else if, or potentially better performing (u=
nordered) map lookup. However, the same could be said about the integral ca=
se, yet we have switch available in that case. So this is at best illogical=
..</div><div><br></div><div>At a more fundamental level, when I use switch, =
I say to the compiler and the readers of the program, &quot;I want a select=
ion from a <i>mutually exclusive</i> list of options; please do so <i>as ef=
ficiently as possible</i>&quot;. This is a hint to the compiler that it is =
free to use something better than a sequential scan. For example, a perfect=
 hash table - try implementing that without compiler support!</div><div><br=
></div><div>Being able to use switch with non-integral types would really m=
ake it switch v2. Just addressing the inconveniences listed above falls way=
 short of that.</div><div><br></div><div>The compile-type constant labels a=
re a somewhat different issue. It is true that without them being compile-t=
ime constant, there is no way to ensure that the options are mutually exclu=
sive at the compile time, and less latitude for optimisation. Yet I think t=
his might also be a useful feature, still more valuable than purely syntact=
ic improvements.</div><div><br></div><div>&gt; * break is not usually the d=
efault I want.<br></div><div><br></div><div>I do not think I understood you=
 here.</div><div><br></div><div>Cheers,</div><div>V.</div><div><br></div></=
div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1yvEwNO-cKBoHn8qpa2cERK_nSEHUK=
8YdW8jb54nYNSg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1yvEwNO-cK=
BoHn8qpa2cERK_nSEHUK8YdW8jb54nYNSg%40mail.gmail.com</a>.<br />

--94eb2c1abc0690c84d05456bc4f3--

.

------=_Part_674_824564697.1483704854083
Content-Type: multipart/alternative;
 boundary="----=_Part_675_699465154.1483704854084"

------=_Part_675_699465154.1483704854084
Content-Type: text/plain; charset=UTF-8



On Saturday, January 7, 2017 at 12:51:28 AM UTC+13, Magnus Fromreide wrote:
>
> On Fri, Jan 06, 2017 at 03:12:27AM -0800, gmis...@gmail.com <javascript:>
> wrote:
> >
> >
> > On Friday, January 6, 2017 at 9:43:44 PM UTC+13, Magnus Fromreide wrote:
> > >
> > > On Thu, Jan 05, 2017 at 03:32:08PM -0800, gmis...@gmail.com
> <javascript:>
> > > wrote:
> > > > Hi all
> > > >
> > > > I'd like to revisit the C++ switch statement debate again.
> > > >
> > > > I am thinking this so far:
> > > >
> > > > (Note This is not a proposal to modify the existing switch statement
> in
> > > any
> > > > way as yet.)
> > > >
> > > > switch v2
> > > > ---------
> > > >
> > > > // switch v2 example:
> > > >
> > > > switch (x) // Supports the new (e; x) too of course.
> > > > case a:
> > > >   for ( a: c )
> > > >     if (whatever)
> > > >         switch break;
> > > > case b:
> > > >     switch (y)
> > > >     case 1:
> > > >     case 2:
> > > >     case 3:
> > > >     switch;
> > > > case c:
> > > >     whatever();
> > > > default:
> > > >     whatever_else();
> > > >
> > > > switch;
> > > >
> > > > // end example.
> > > >
> > > >
> > > > Changes from classic switch:
> > > > * The new switch begins with no brace. This ditinquishes it from the
> > > > classic switch.
> > >
> > > There is no requirement of braces in a classic switch.
> > >
> > > > * switch ends with a switch; statement.
> > >
> > > This would break my code. I am using
> > >
> > > #define FOO switch (0) default: type name
> > >
> > > rather than the more common
> > >
> > > #define FOO if (false) ; else type name
> > >
> > > when I need to declare an open scope in order to explain to compilers
> that
> > > I
> > > haven't messed up my else nesting.
> > >
> > > Please ensure that open scopes are preserved.
> > >
> > > > 1. Would this new syntax create any obvious parsing issues that
> would
> > > make
> > > > it a no go.
> > >
> > > Yes. There is no requirement of braces in a switch statement,
> > >
> > > /MF
> > >
> >
> > If pains me to care about that, but if we must, then changing the
> proposal
> > to switch break (x) to open a switch
> > would seem to fix your issue? I'd be ok with that. Would you?
>
> It would move the proposal out of the breaking change space so I would not
> be
> "over my dead body" about it.
>
> I still predict that you will find it hard to convice the commmitte given
> that
> this looks pretty alien to the rest of C++ and adds very little value.
>
> #define BEGIN MY_SWITCH(...) switch (__VA_ARGS__) {
> #define MY_SWITCH_CASE break; case
> #define END_MY_SWITCH }
>
> /MF
>

I agreed that the Committee will take reasonable persuasion here.
I don't know myself yet.
But if we can iron out some basic non starters and kinks it might take
shape.

I don't think your macro is an acceptable solution though.
People are trying to avoid macros and modules aims to dent them further.
I would never put your suggested code into a code base and I don't anyone
else would, you included.
I'd live without than do that.

So I think that means it's worth investigating a little further to see what
takes shape because macro's isn't going to be viable for anybody.

--
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/39ff01a8-bfb1-4eef-b4c5-c48cac0314f7%40isocpp.org.

------=_Part_675_699465154.1483704854084
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, January 7, 2017 at 12:51:28 AM UTC+13=
, Magnus Fromreide wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204=
); border-left-width: 1px; border-left-style: solid;">On Fri, Jan 06, 2017 =
at 03:12:27AM -0800, <a onmousedown=3D"this.href=3D&#39;javascript:&#39;;re=
turn true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=
=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=
=3D"aqaBaDdVDAAJ">gmis...@gmail.com</a> wrote:
<br>&gt;=20
<br>&gt;=20
<br>&gt; On Friday, January 6, 2017 at 9:43:44 PM UTC+13, Magnus Fromreide =
wrote:
<br>&gt; &gt;
<br>&gt; &gt; On Thu, Jan 05, 2017 at 03:32:08PM -0800, <a>gmis...@gmail.co=
m</a> &lt;javascript:&gt;=20
<br>&gt; &gt; wrote:=20
<br>&gt; &gt; &gt; Hi all=20
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; I&#39;d like to revisit the C++ switch statement debate =
again.=20
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; I am thinking this so far:=20
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; (Note This is not a proposal to modify the existing swit=
ch statement in=20
<br>&gt; &gt; any=20
<br>&gt; &gt; &gt; way as yet.)=20
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; switch v2=20
<br>&gt; &gt; &gt; ---------=20
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; // switch v2 example:=20
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; switch (x) // Supports the new (e; x) too of course.=20
<br>&gt; &gt; &gt; case a:=20
<br>&gt; &gt; &gt; =C2=A0 for ( a: c )=20
<br>&gt; &gt; &gt; =C2=A0 =C2=A0 if (whatever)=20
<br>&gt; &gt; &gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 switch break;=20
<br>&gt; &gt; &gt; case b:=20
<br>&gt; &gt; &gt; =C2=A0 =C2=A0 switch (y)=20
<br>&gt; &gt; &gt; =C2=A0 =C2=A0 case 1:=20
<br>&gt; &gt; &gt; =C2=A0 =C2=A0 case 2:=20
<br>&gt; &gt; &gt; =C2=A0 =C2=A0 case 3:=20
<br>&gt; &gt; &gt; =C2=A0 =C2=A0 switch;=20
<br>&gt; &gt; &gt; case c:=20
<br>&gt; &gt; &gt; =C2=A0 =C2=A0 whatever();=20
<br>&gt; &gt; &gt; default:=20
<br>&gt; &gt; &gt; =C2=A0 =C2=A0 whatever_else();=20
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; switch;=20
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; // end example.=20
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; Changes from classic switch:=20
<br>&gt; &gt; &gt; * The new switch begins with no brace. This ditinquishes=
 it from the=20
<br>&gt; &gt; &gt; classic switch.=20
<br>&gt; &gt;
<br>&gt; &gt; There is no requirement of braces in a classic switch.=20
<br>&gt; &gt;
<br>&gt; &gt; &gt; * switch ends with a switch; statement.=20
<br>&gt; &gt;
<br>&gt; &gt; This would break my code. I am using=20
<br>&gt; &gt;
<br>&gt; &gt; #define FOO switch (0) default: type name=20
<br>&gt; &gt;
<br>&gt; &gt; rather than the more common=20
<br>&gt; &gt;
<br>&gt; &gt; #define FOO if (false) ; else type name=20
<br>&gt; &gt;
<br>&gt; &gt; when I need to declare an open scope in order to explain to c=
ompilers that=20
<br>&gt; &gt; I=20
<br>&gt; &gt; haven&#39;t messed up my else nesting.=20
<br>&gt; &gt;
<br>&gt; &gt; Please ensure that open scopes are preserved.=20
<br>&gt; &gt;
<br>&gt; &gt; &gt; 1. Would this new syntax create any obvious parsing issu=
es that would=20
<br>&gt; &gt; make=20
<br>&gt; &gt; &gt; it a no go.=20
<br>&gt; &gt;
<br>&gt; &gt; Yes. There is no requirement of braces in a switch statement,=
=20
<br>&gt; &gt;
<br>&gt; &gt; /MF=20
<br>&gt; &gt;
<br>&gt;=20
<br>&gt; If pains me to care about that, but if we must, then changing the =
proposal=20
<br>&gt; to switch break (x) to open a switch
<br>&gt; would seem to fix your issue? I&#39;d be ok with that. Would you?
<br>
<br>It would move the proposal out of the breaking change space so I would =
not be
<br>&quot;over my dead body&quot; about it.
<br>
<br>I still predict that you will find it hard to convice the commmitte giv=
en that
<br>this looks pretty alien to the rest of C++ and adds very little value.
<br>
<br>#define BEGIN MY_SWITCH(...) switch (__VA_ARGS__) {
<br>#define MY_SWITCH_CASE break; case
<br>#define END_MY_SWITCH }
<br>
<br>/MF
<br></blockquote><div><br></div><div>I agreed that the Committee will take =
reasonable persuasion here.</div><div>I don&#39;t know myself yet.</div><di=
v>But if we can iron out some basic non starters and kinks it might take sh=
ape.</div><div><br></div><div>I don&#39;t think your macro is an acceptable=
 solution though.</div><div>People are trying to avoid macros and modules a=
ims to=C2=A0dent them further.</div><div>I would never put=C2=A0your sugges=
ted=C2=A0code into a code base and I don&#39;t anyone else would, you inclu=
ded.</div><div>I&#39;d live without than do=C2=A0that.</div><div><br></div>=
<div>So I think that means it&#39;s worth=C2=A0investigating a little furth=
er to see what takes shape because macro&#39;s isn&#39;t going to be viable=
 for anybody.</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/39ff01a8-bfb1-4eef-b4c5-c48cac0314f7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/39ff01a8-bfb1-4eef-b4c5-c48cac0314f7=
%40isocpp.org</a>.<br />

------=_Part_675_699465154.1483704854084--

------=_Part_674_824564697.1483704854083--

.

------=_Part_704_674112773.1483707213321
Content-Type: multipart/alternative;
 boundary="----=_Part_705_955051786.1483707213321"

------=_Part_705_955051786.1483707213321
Content-Type: text/plain; charset=UTF-8



On Saturday, January 7, 2017 at 1:00:47 AM UTC+13, Viacheslav Usov wrote:
>
> On Fri, Jan 6, 2017 at 12:32 AM, <gmis...@gmail.com <javascript:>> wrote:
>
> > * I hate trying to format switches. I'd like less nesting and brace
> ambiguity and formatting concerns here.
>
> > * I really hate not having a scope available by default and getting an
> error.
>
> > * I find switch verbose.
>
> The above are *nuisances.* They do not *preclude* the use of a switch
> statement.
>
> A real* problem* with the existing switch statement is that its
> conditional expression must be (essentially) of an integral type, and case
> labels compile-time constants. If I want something else, a typical case
> being strings, I *cannot use* the switch statement.
>
> In the latter case it might be argued that I could achieve what I want to
> by using else if, or potentially better performing (unordered) map lookup.
> However, the same could be said about the integral case, yet we have switch
> available in that case. So this is at best illogical.
>
> At a more fundamental level, when I use switch, I say to the compiler and
> the readers of the program, "I want a selection from a *mutually
> exclusive* list of options; please do so *as efficiently as possible*".
> This is a hint to the compiler that it is free to use something better than
> a sequential scan. For example, a perfect hash table - try implementing
> that without compiler support!
>
> Being able to use switch with non-integral types would really make it
> switch v2. Just addressing the inconveniences listed above falls way short
> of that.
>
> The compile-type constant labels are a somewhat different issue. It is
> true that without them being compile-time constant, there is no way to
> ensure that the options are mutually exclusive at the compile time, and
> less latitude for optimisation. Yet I think this might also be a useful
> feature, still more valuable than purely syntactic improvements.
>
> > * break is not usually the default I want.
>
> I do not think I understood you here.
>
> Cheers,
> V.
>

When I said break is not usually the default I want. I meant to say I want
break to automatically happen at the end of a case without explicitly
saying break or break switch. I want something explicit like a fallthrough
keyword or demand goto label be used.

I agree with all you've said,  but I want to start small as IMO
whatever the real switch V2 is, it has to have a basic workable structure
that does what switch V1 does in order to graft all that other stuff you
want on to. And I'd like that basic V2 switch to not have what I consider
to be the same warts of the existing V1 switch. That's what I'm thinking.

So I think the additional parts you mention are correct but could/should be
put to the committee as pieces and possibly debated more heavily and maybe
in another thread once the basics are nailed down.

The basic V2 switch I want has a cleaner syntax that is easier to format
and use. To me that means it has automatic scopes, case that break at the
end automatically and a structure that minimizes nesting and an excess
braces. That seem important to me.

I expect an uphill struggle because we didn't get there last time,
but hopefully if people remain positive in ideas first and more
critical nearer and end result we might get something more viable this
time. If we nail the basics we can build on it.

What's a basic switch that you'd support look like that does just V1 switch
abilities?
I'm happy to assume your real support might imply getting the other things
you want too. I'm just focus small first and see what that looks like.

--
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/dea558cc-8d68-482f-a6cd-3e71d30ae8f1%40isocpp.org.

------=_Part_705_955051786.1483707213321
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, January 7, 2017 at 1:00:47 AM UTC+13,=
 Viacheslav Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204);=
 border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><=
div class=3D"gmail_quote">On Fri, Jan 6, 2017 at 12:32 AM,  <span dir=3D"lt=
r">&lt;<a onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" on=
click=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"javascript=
:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"MLQIi7lVDAAJ=
">gmis...@gmail.com</a>&gt;</span> wrote:<br><div><br></div><div>&gt; * I=
=C2=A0hate trying to format switches.=C2=A0I&#39;d like=C2=A0less nesting a=
nd brace ambiguity and formatting concerns here.</div><div><br></div><div>&=
gt; * I really hate not having a scope available by default and getting an =
error.</div><div><br></div><div>&gt; * I find switch verbose.</div><div><br=
></div><div>The above are <i>nuisances.</i>=C2=A0They do not <i>preclude</i=
> the use of a switch statement.</div><div><br></div><div>A real<i>=C2=A0pr=
oblem</i>=C2=A0with the existing switch statement is that its conditional e=
xpression must be (essentially) of an integral type, and case labels compil=
e-time constants. If I want something else, a typical case being strings, I=
 <i>cannot use</i> the switch statement.</div><div><br></div><div>In the la=
tter case it might be argued that I could achieve what I want to by using e=
lse if, or potentially better performing (unordered) map lookup. However, t=
he same could be said about the integral case, yet we have switch available=
 in that case. So this is at best illogical.</div><div><br></div><div>At a =
more fundamental level, when I use switch, I say to the compiler and the re=
aders of the program, &quot;I want a selection from a <i>mutually exclusive=
</i> list of options; please do so <i>as efficiently as possible</i>&quot;.=
 This is a hint to the compiler that it is free to use something better tha=
n a sequential scan. For example, a perfect hash table - try implementing t=
hat without compiler support!</div><div><br></div><div>Being able to use sw=
itch with non-integral types would really make it switch v2. Just addressin=
g the inconveniences listed above falls way short of that.</div><div><br></=
div><div>The compile-type constant labels are a somewhat different issue. I=
t is true that without them being compile-time constant, there is no way to=
 ensure that the options are mutually exclusive at the compile time, and le=
ss latitude for optimisation. Yet I think this might also be a useful featu=
re, still more valuable than purely syntactic improvements.</div><div><br><=
/div><div>&gt; * break is not usually the default I want.<br></div><div><br=
></div><div>I do not think I understood you here.</div><div><br></div><div>=
Cheers,</div><div>V.</div></div></div></div></blockquote><div><br></div><di=
v><div>When I said=C2=A0break is not usually the default I want. I meant to=
 say I want break to automatically happen at the end of a case=C2=A0without=
 explicitly saying break or break switch.=C2=A0I want something explicit li=
ke=C2=A0a fallthrough keyword or demand goto label be used.</div><div><br><=
/div></div><div>I agree with all you&#39;ve said,=C2=A0 but=C2=A0I=C2=A0wan=
t to start small as IMO whatever=C2=A0the real=C2=A0switch V2 is, it has to=
=C2=A0have a basic=C2=A0workable structure that does what switch V1 does in=
 order=C2=A0to graft all that other stuff you want on to. And I&#39;d like =
that basic V2 switch=C2=A0to not have what I consider to be the same warts =
of the existing=C2=A0V1 switch. That&#39;s what I&#39;m thinking.</div><div=
><br></div><div>So I=C2=A0think the additional parts you mention are=C2=A0c=
orrect but could/should be put to the committee as pieces and possibly deba=
ted more heavily and maybe in another thread once the basics are nailed dow=
n.</div><div><br></div><div><div>The basic=C2=A0V2 switch I want has a clea=
ner syntax that is=C2=A0easier to format and use. To me that=C2=A0means it =
has automatic scopes, case that break=C2=A0at the end automatically=C2=A0an=
d=C2=A0a structure=C2=A0that minimizes=C2=A0nesting and an excess braces. T=
hat seem important=C2=A0to me.</div><div><br></div><div>I expect an=C2=A0up=
hill struggle because we didn&#39;t get there last time, but=C2=A0hopefully=
 if people=C2=A0remain positive in ideas first and more critical=C2=A0neare=
r and end result we might get something=C2=A0more viable this time. If we n=
ail the basics we can build on=C2=A0it.</div><div><br></div><div>What&#39;s=
 a basic switch that you&#39;d support look like that does just V1 switch a=
bilities?</div><div>I&#39;m happy to=C2=A0assume your real support=C2=A0mig=
ht imply=C2=A0getting the other things you want too.=C2=A0I&#39;m just focu=
s small first and see what that looks like.</div><div><br></div></div></div=
>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/dea558cc-8d68-482f-a6cd-3e71d30ae8f1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dea558cc-8d68-482f-a6cd-3e71d30ae8f1=
%40isocpp.org</a>.<br />

------=_Part_705_955051786.1483707213321--

------=_Part_704_674112773.1483707213321--

.

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

On Fri, Jan 6, 2017 at 12:53 PM, <gmisocpp@gmail.com> wrote:

>
> The basic V2 switch I want has a cleaner syntax that is easier to format
> and use. To me that means it has automatic scopes, case that break at the
> end automatically and a structure that minimizes nesting and an excess
> braces. That seem important to me.
>

Where does it end? Should we move to using if (blah): foo(); if; too?
Should we stop using braces altogether and become Python? It seems like
you're taking issue with fundamental concepts of C++ but then proposing to
change them only for one type of control structure.

--
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/CACGiwhExjj%3Dq_7_1uE3z%3DXyKijHE46-BsEBmCG_h9P5%2BoRE8BA%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Jan 6, 2017 at 12:53 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:gmiso=
cpp@gmail.com" target=3D"_blank">gmisocpp@gmail.com</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div><div>The basic=
=C2=A0V2 switch I want has a cleaner syntax that is=C2=A0easier to format a=
nd use. To me that=C2=A0means it has automatic scopes, case that break=C2=
=A0at the end automatically=C2=A0and=C2=A0a structure=C2=A0that minimizes=
=C2=A0nesting and an excess braces. That seem important=C2=A0to me.</div></=
div></div></blockquote><div><br></div><div>Where does it end? Should we mov=
e to using <span style=3D"font-family:monospace,monospace">if (blah): foo()=
; if;</span> too? Should we stop using braces altogether and become Python?=
 It seems like you&#39;re taking issue with fundamental concepts of C++ but=
 then proposing to change them only for one type of control structure.<br><=
/div></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhExjj%3Dq_7_1uE3z%3DXyKijHE46-B=
sEBmCG_h9P5%2BoRE8BA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhExjj=
%3Dq_7_1uE3z%3DXyKijHE46-BsEBmCG_h9P5%2BoRE8BA%40mail.gmail.com</a>.<br />

--f403045eaca82798d805456d1608--

.

------=_Part_153_1035037713.1483712125652
Content-Type: multipart/alternative;
 boundary="----=_Part_154_848658256.1483712125653"

------=_Part_154_848658256.1483712125653
Content-Type: text/plain; charset=UTF-8

On Friday, January 6, 2017 at 7:53:33 AM UTC-5, gmis...@gmail.com wrote:
>
> The basic V2 switch I want has a cleaner syntax that is easier to format
> and use. To me that means it has automatic scopes, case that break at the
> end automatically and a structure that minimizes nesting and an excess
> braces. That seem important to me.
>

It has a syntax that is fundamentally different from *anything else in C++*.
Your definition of "clean" is to not use braces. Well... *tough*. Curly
braces is how C++ defines scopes. Pretty much everything that defines a
scope uses them: functions, classes, if/for/while/do, etc.

Why should we change something that fundamental to how the language looks,
just because one person doesn't like using braces for scopes? How does this
*objectively*, or even semi-objectively, improve the language?

Consistency of the language is more important than one user's comfort

--
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/d0bfed88-9452-4f59-bc0d-df1580d435f9%40isocpp.org.

------=_Part_154_848658256.1483712125653
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, January 6, 2017 at 7:53:33 AM UTC-5, gmis...@gm=
ail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div></div><div><div>The basic=C2=A0V2 switch I want has a cleaner syntax =
that is=C2=A0easier to format and use. To me that=C2=A0means it has automat=
ic scopes, case that break=C2=A0at the end automatically=C2=A0and=C2=A0a st=
ructure=C2=A0that minimizes=C2=A0nesting and an excess braces. That seem im=
portant=C2=A0to me.</div></div></div></blockquote><div><br>It has a syntax =
that is fundamentally different from <i>anything else in C++</i>. Your defi=
nition of &quot;clean&quot; is to not use braces. Well... <i>tough</i>. Cur=
ly braces is how C++ defines scopes. Pretty much everything that defines a =
scope uses them: functions, classes, if/for/while/do, etc.<br><br>Why shoul=
d we change something that fundamental to how the language looks, just beca=
use one person doesn&#39;t like using braces for scopes? How does this <i>o=
bjectively</i>, or even semi-objectively, improve the language?<br><br>Cons=
istency of the language is more important than one user&#39;s comfort<br></=
div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d0bfed88-9452-4f59-bc0d-df1580d435f9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d0bfed88-9452-4f59-bc0d-df1580d435f9=
%40isocpp.org</a>.<br />

------=_Part_154_848658256.1483712125653--

------=_Part_153_1035037713.1483712125652--

.

------=_Part_764_207779603.1483712360867
Content-Type: multipart/alternative;
 boundary="----=_Part_765_184041182.1483712360868"

------=_Part_765_184041182.1483712360868
Content-Type: text/plain; charset=UTF-8



On Saturday, January 7, 2017 at 2:35:11 AM UTC+13, D. B. wrote:
>
> On Fri, Jan 6, 2017 at 12:53 PM, <gmis...@gmail.com <javascript:>> wrote:
>
>>
>> The basic V2 switch I want has a cleaner syntax that is easier to format
>> and use. To me that means it has automatic scopes, case that break at the
>> end automatically and a structure that minimizes nesting and an excess
>> braces. That seem important to me.
>>
>
> Where does it end? Should we move to using if (blah): foo(); if; too?
> Should we stop using braces altogether and become Python? It seems like
> you're taking issue with fundamental concepts of C++ but then proposing to
> change them only for one type of control structure.
>

It was the braces in switch V1 that I found were making the formatting
clumsy so I had to attack that problem and remove them in my opinion to fix
that. Maybe you have a better suggestion?

I see that it may seem confronting initially to use "switch;" to close but
that might seem less so if you consider modules and namespaces
actually benefit from the same treatment and then it's not so unusual.

Regarding "if", that's used often and often at small scope, so using "fi"
to close is as verbosely unpleasant for those small blocks as it might be
pleasant for large blocks so on balance there isn't any value using "fi" to
me. So no I wouldn't propose that. It would stop there.

Also "if" doesn't name things. Modules and name spaces do and enclose much
larger blocks where it's easier to lose track of what you are locking at.
I've often been at the left border on a brace and not being sure what it
was and what also encourages me with this idea is I've also often found
people attempt had the same experience and attempt to address that by
commenting after the brace with the namespace name etc. and then I find
it's wrong because someone later changed the namespace but not the comment
to match.

If people are using that style we can accommodate it better with what I
proposed. Why use a comment to address what you can enforce in code.
The happy result of adopting that would also be that it makes
the "switch;" thing seem less of an oddity. Win/Win

switches are also often quite huge even if you can put many of the
cases logic in a function. See llvm. So knowing where a switch ends in a
bunch of other braces can be handy I think.

In summary, I don't think it's so weird and there is some justification for
all of this especially if these pieces fit together ok as they might.
I'm not sure yet but I have an open mind to It so far.

--
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/cb71d911-d96d-48cf-b426-5b217c55b88c%40isocpp.org.

------=_Part_765_184041182.1483712360868
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, January 7, 2017 at 2:35:11 AM UTC+13,=
 D. B. wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px=
 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-le=
ft-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">On Fri, Jan 6, 2017 at 12:53 PM,  <span dir=3D"ltr">&lt;<a=
 onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"=
this.href=3D&#39;javascript:&#39;;return true;" href=3D"javascript:" target=
=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"4eHITuBaDAAJ">gmis...=
@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;"><div dir=
=3D"ltr"><br><div><div>The basic=C2=A0V2 switch I want has a cleaner syntax=
 that is=C2=A0easier to format and use. To me that=C2=A0means it has automa=
tic scopes, case that break=C2=A0at the end automatically=C2=A0and=C2=A0a s=
tructure=C2=A0that minimizes=C2=A0nesting and an excess braces. That seem i=
mportant=C2=A0to me.</div></div></div></blockquote><div><br></div><div>Wher=
e does it end? Should we move to using <span style=3D"font-family: monospac=
e,monospace;">if (blah): foo(); if;</span> too? Should we stop using braces=
 altogether and become Python? It seems like you&#39;re taking issue with f=
undamental concepts of C++ but then proposing to change them only for one t=
ype of control structure.<br></div></div></div></div></blockquote><div><br>=
</div><div>It was the braces in switch V1 that=C2=A0I found were making the=
 formatting clumsy so I=C2=A0had to attack that problem and remove them in =
my opinion to fix that. Maybe you have a better suggestion?</div><div><br><=
/div><div>I see that it may seem confronting initially to use &quot;switch;=
&quot; to close=C2=A0but that might seem less so if you consider modules an=
d namespaces</div><div>actually benefit from the same treatment and=C2=A0th=
en it&#39;s=C2=A0not so unusual.</div><div><br></div><div><div><div>Regardi=
ng &quot;if&quot;, that&#39;s=C2=A0used often and often at small scope, so =
using &quot;fi&quot; to close is as verbosely unpleasant=C2=A0for=C2=A0thos=
e small blocks as it might be pleasant for large blocks so on balance there=
 isn&#39;t any value using &quot;fi&quot; to me. So no I wouldn&#39;t propo=
se that. It would stop there.</div><div><br></div><div>Also=C2=A0&quot;if&q=
uot; doesn&#39;t name things. Modules and name spaces do and enclose much l=
arger blocks=C2=A0where it&#39;s easier to lose track of what you are locki=
ng at. I&#39;ve=C2=A0often been at the left border on a brace and not being=
 sure what it was=C2=A0and what also encourages me with this idea is=C2=A0I=
&#39;ve also=C2=A0often found people=C2=A0attempt=C2=A0had the same experie=
nce and attempt to address that=C2=A0by commenting after the brace with the=
=C2=A0namespace name etc. and then I find it&#39;s=C2=A0wrong because=C2=A0=
someone later changed the namespace but not the comment to match.</div><div=
><br></div><div>If people are using that style we can accommodate it better=
 with what I proposed. Why use a comment to address what you can enforce in=
 code. </div><div>The happy result of adopting that would also be that=C2=
=A0it makes the=C2=A0&quot;switch;&quot;=C2=A0thing=C2=A0seem less of an od=
dity. Win/Win</div><div><br></div></div></div><div><div><div>switches are a=
lso often quite huge even if you can put many of the cases=C2=A0logic=C2=A0=
in a function. See llvm. So knowing where a switch ends in a bunch of other=
 braces can be handy I think.</div><div><br></div><div>In summary, I don&#3=
9;t think it&#39;s so weird and there is some justification for all of this=
 especially if these pieces fit=C2=A0together ok as they might.</div><div>I=
&#39;m not sure yet but I have an open mind to It so far.</div></div></div>=
</div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cb71d911-d96d-48cf-b426-5b217c55b88c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cb71d911-d96d-48cf-b426-5b217c55b88c=
%40isocpp.org</a>.<br />

------=_Part_765_184041182.1483712360868--

------=_Part_764_207779603.1483712360867--

.

------=_Part_805_421128389.1483713247688
Content-Type: multipart/alternative;
 boundary="----=_Part_806_977221633.1483713247689"

------=_Part_806_977221633.1483713247689
Content-Type: text/plain; charset=UTF-8



On Saturday, January 7, 2017 at 3:15:25 AM UTC+13, Nicol Bolas wrote:
>
> On Friday, January 6, 2017 at 7:53:33 AM UTC-5, gmis...@gmail.com wrote:
>>
>> The basic V2 switch I want has a cleaner syntax that is easier to format
>> and use. To me that means it has automatic scopes, case that break at the
>> end automatically and a structure that minimizes nesting and an excess
>> braces. That seem important to me.
>>
>
> It has a syntax that is fundamentally different from *anything else in
> C++*. Your definition of "clean" is to not use braces. Well... *tough*.
> Curly braces is how C++ defines scopes. Pretty much everything that defines
> a scope uses them: functions, classes, if/for/while/do, etc.
>
> Why should we change something that fundamental to how the language looks,
> just because one person doesn't like using braces for scopes? How does this
> *objectively*, or even semi-objectively, improve the language?
>
> Consistency of the language is more important than one user's comfort
>

I've offered my answer to this in another reply. But I as yet don't see any
essential consistency lost here yet but it's too soon to say. I think we
have to see what ideas come forth and how they fit together as a whole
before judging too harshly. We should also factor in what we might gain
here against what we might lose. We likely need a new switch to add all the
other things we want beyond formatting issues too. If you can do all
that without any loss anywhere then great but we can't judge a loss until
we know the gains we get with it and that's still being worked through here
so bare with it I'd ask and lets see.

--
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/79a275c1-f09f-4a3f-997f-9524fb708ae9%40isocpp.org.

------=_Part_806_977221633.1483713247689
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, January 7, 2017 at 3:15:25 AM UTC+13,=
 Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">On Friday,=
 January 6, 2017 at 7:53:33 AM UTC-5, <a>gmis...@gmail.com</a> wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-lef=
t: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bord=
er-left-style: solid;"><div dir=3D"ltr"><div></div><div><div>The basic=C2=
=A0V2 switch I want has a cleaner syntax that is=C2=A0easier to format and =
use. To me that=C2=A0means it has automatic scopes, case that break=C2=A0at=
 the end automatically=C2=A0and=C2=A0a structure=C2=A0that minimizes=C2=A0n=
esting and an excess braces. That seem important=C2=A0to me.</div></div></d=
iv></blockquote><div><br>It has a syntax that is fundamentally different fr=
om <i>anything else in C++</i>. Your definition of &quot;clean&quot; is to =
not use braces. Well... <i>tough</i>. Curly braces is how C++ defines scope=
s. Pretty much everything that defines a scope uses them: functions, classe=
s, if/for/while/do, etc.<br><br>Why should we change something that fundame=
ntal to how the language looks, just because one person doesn&#39;t like us=
ing braces for scopes? How does this <i>objectively</i>, or even semi-objec=
tively, improve the language?<br><br>Consistency of the language is more im=
portant than one user&#39;s comfort<br></div></div></blockquote><div><br></=
div><div>I&#39;ve offered=C2=A0my=C2=A0answer=C2=A0to this in another reply=
..=C2=A0But I as yet=C2=A0don&#39;t=C2=A0see any essential consistency lost =
here yet but it&#39;s too soon to say. I think=C2=A0we have to=C2=A0see wha=
t ideas come forth and how they=C2=A0fit=C2=A0together as a whole before ju=
dging too harshly.=C2=A0We should also factor in=C2=A0what we might gain he=
re against what we might lose. We likely need a new switch to add all the o=
ther things we want beyond=C2=A0formatting issues too. If you can do all th=
at=C2=A0without=C2=A0any=C2=A0loss anywhere then great but=C2=A0we can&#39;=
t judge a loss until we know the gains we get with it and=C2=A0that&#39;s s=
till being worked through here so bare with it I&#39;d ask and lets see.</d=
iv></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/79a275c1-f09f-4a3f-997f-9524fb708ae9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/79a275c1-f09f-4a3f-997f-9524fb708ae9=
%40isocpp.org</a>.<br />

------=_Part_806_977221633.1483713247689--

------=_Part_805_421128389.1483713247688--

.

------=_Part_226_300012519.1483715444217
Content-Type: multipart/alternative;
 boundary="----=_Part_227_1601613466.1483715444217"

------=_Part_227_1601613466.1483715444217
Content-Type: text/plain; charset=UTF-8

On Friday, January 6, 2017 at 9:34:07 AM UTC-5, gmis...@gmail.com wrote:
>
> On Saturday, January 7, 2017 at 3:15:25 AM UTC+13, Nicol Bolas wrote:
>>
>> On Friday, January 6, 2017 at 7:53:33 AM UTC-5, gmis...@gmail.com wrote:
>>>
>>> The basic V2 switch I want has a cleaner syntax that is easier to format
>>> and use. To me that means it has automatic scopes, case that break at the
>>> end automatically and a structure that minimizes nesting and an excess
>>> braces. That seem important to me.
>>>
>>
>> It has a syntax that is fundamentally different from *anything else in
>> C++*. Your definition of "clean" is to not use braces. Well... *tough*.
>> Curly braces is how C++ defines scopes. Pretty much everything that defines
>> a scope uses them: functions, classes, if/for/while/do, etc.
>>
>> Why should we change something that fundamental to how the language
>> looks, just because one person doesn't like using braces for scopes? How
>> does this *objectively*, or even semi-objectively, improve the language?
>>
>> Consistency of the language is more important than one user's comfort
>>
>
> I've offered my answer to this in another reply. But I as yet don't see
> any essential consistency lost here yet
>

Of course *you* don't; you have already said that you don't like curly
braces. That doesn't chance the fact that this would be the first place in
C++ that defines a scope without braces (or without being limited to a
single statement).

You cannot deny that what you have proposed is a novel grammar to C++.


> but it's too soon to say. I think we have to see what ideas come forth and
> how they fit together as a whole before judging too harshly.
>

I don't understand what you're talking about with regard to "what ideas
come forth". If you're talking about what other features people might throw
into this proposal, those "ideas" would work just as effectively in a
`switch` statement that uses standard C++ grammar.

We should also factor in what we might gain here against what we might
> lose. We likely need a new switch to add all the other things we want
> beyond formatting issues too.
>

And when we get one, *it will use curly braces*.

--
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/e2c94517-1f97-41ad-932b-04d2d026d616%40isocpp.org.

------=_Part_227_1601613466.1483715444217
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, January 6, 2017 at 9:34:07 AM UTC-5, gmis...@gm=
ail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>On Saturday, January 7, 2017 at 3:15:25 AM UTC+13, Nicol Bolas wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left=
:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-s=
tyle:solid"><div dir=3D"ltr">On Friday, January 6, 2017 at 7:53:33 AM UTC-5=
, <a>gmis...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,20=
4);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div></d=
iv><div><div>The basic=C2=A0V2 switch I want has a cleaner syntax that is=
=C2=A0easier to format and use. To me that=C2=A0means it has automatic scop=
es, case that break=C2=A0at the end automatically=C2=A0and=C2=A0a structure=
=C2=A0that minimizes=C2=A0nesting and an excess braces. That seem important=
=C2=A0to me.</div></div></div></blockquote><div><br>It has a syntax that is=
 fundamentally different from <i>anything else in C++</i>. Your definition =
of &quot;clean&quot; is to not use braces. Well... <i>tough</i>. Curly brac=
es is how C++ defines scopes. Pretty much everything that defines a scope u=
ses them: functions, classes, if/for/while/do, etc.<br><br>Why should we ch=
ange something that fundamental to how the language looks, just because one=
 person doesn&#39;t like using braces for scopes? How does this <i>objectiv=
ely</i>, or even semi-objectively, improve the language?<br><br>Consistency=
 of the language is more important than one user&#39;s comfort<br></div></d=
iv></blockquote><div><br></div><div>I&#39;ve offered=C2=A0my=C2=A0answer=C2=
=A0to this in another reply.=C2=A0But I as yet=C2=A0don&#39;t=C2=A0see any =
essential consistency lost here yet</div></div></blockquote><div><br>Of cou=
rse <i>you</i> don&#39;t; you have already said that you don&#39;t like cur=
ly braces. That doesn&#39;t chance the fact that this would be the first pl=
ace in C++ that defines a scope without braces (or without being limited to=
 a single statement).<br><br>You cannot deny that what you have proposed is=
 a novel grammar to C++.<br>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div> but it&#39;s too soon to say. I think=C2=
=A0we have to=C2=A0see what ideas come forth and how they=C2=A0fit=C2=A0tog=
ether as a whole before judging too harshly.</div></div></blockquote><div><=
br>I don&#39;t understand what you&#39;re talking about with regard to &quo=
t;what ideas come forth&quot;. If you&#39;re talking about what other featu=
res people might throw into this proposal, those &quot;ideas&quot; would wo=
rk just as effectively in a `switch` statement that uses standard C++ gramm=
ar.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>We should also factor in=C2=A0what we might gain here against what=
 we might lose. We likely need a new switch to add all the other things we =
want beyond=C2=A0formatting issues too.</div></div></blockquote><div><br>An=
d when we get one, <i>it will use curly braces</i>.</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e2c94517-1f97-41ad-932b-04d2d026d616%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e2c94517-1f97-41ad-932b-04d2d026d616=
%40isocpp.org</a>.<br />

------=_Part_227_1601613466.1483715444217--

------=_Part_226_300012519.1483715444217--

.

------=_Part_855_1641150763.1483718976149
Content-Type: multipart/alternative;
 boundary="----=_Part_856_2043653415.1483718976149"

------=_Part_856_2043653415.1483718976149
Content-Type: text/plain; charset=UTF-8



On Saturday, January 7, 2017 at 4:10:44 AM UTC+13, Nicol Bolas wrote:
>
> On Friday, January 6, 2017 at 9:34:07 AM UTC-5, gmis...@gmail.com wrote:
>>
>> On Saturday, January 7, 2017 at 3:15:25 AM UTC+13, Nicol Bolas wrote:
>>>
>>> On Friday, January 6, 2017 at 7:53:33 AM UTC-5, gmis...@gmail.com wrote:
>>>>
>>>> The basic V2 switch I want has a cleaner syntax that is easier to
>>>> format and use. To me that means it has automatic scopes, case that
>>>> break at the end automatically and a structure that minimizes nesting and
>>>> an excess braces. That seem important to me.
>>>>
>>>
>>> It has a syntax that is fundamentally different from *anything else in
>>> C++*. Your definition of "clean" is to not use braces. Well... *tough*.
>>> Curly braces is how C++ defines scopes. Pretty much everything that defines
>>> a scope uses them: functions, classes, if/for/while/do, etc.
>>>
>>> Why should we change something that fundamental to how the language
>>> looks, just because one person doesn't like using braces for scopes? How
>>> does this *objectively*, or even semi-objectively, improve the language?
>>>
>>> Consistency of the language is more important than one user's comfort
>>>
>>
>> I've offered my answer to this in another reply. But I as yet don't see
>> any essential consistency lost here yet
>>
>
> Of course *you* don't; you have already said that you don't like curly
> braces. That doesn't chance the fact that this would be the first place in
> C++ that defines a scope without braces (or without being limited to a
> single statement).
>
> You cannot deny that what you have proposed is a novel grammar to C++.
>

I don't deny it's was novel. I am just saying "switch;" might not seem as
out there if the other suggestions I've made with it were also enacted and
I've presented a rationale why those suggestions might be motivating to
some.

Do you prefer comments to remind people what namespace is ending?
Have you seen people use comments to do that?

If you have seen comments, that might show other people might prefer an
option to check them even if you don't.
We don't know what people prefer until we ask, so I'm asking. I've seen
comments used this way.


>
>
>> but it's too soon to say. I think we have to see what ideas come forth
>> and how they fit together as a whole before judging too harshly.
>>
>
> I don't understand what you're talking about with regard to "what ideas
> come forth". If you're talking about what other features people might throw
> into this proposal, those "ideas" would work just as effectively in a
> `switch` statement that uses standard C++ grammar.
>


> We should also factor in what we might gain here against what we might
>> lose. We likely need a new switch to add all the other things we want
>> beyond formatting issues too.
>>
>
> And when we get one, *it will use curly braces*.
>

I hope you are right, but I didn't like the curly switches I experimented
with so why don't you propose yours and then we can compare which formats
the best? If yours is better I'll happily um switch to it. :)

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/846f9674-66c9-4774-b3b6-7dac43e8ecdf%40isocpp.org.

------=_Part_856_2043653415.1483718976149
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, January 7, 2017 at 4:10:44 AM UTC+13,=
 Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">On Friday,=
 January 6, 2017 at 9:34:07 AM UTC-5, <a>gmis...@gmail.com</a> wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-lef=
t: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bord=
er-left-style: solid;"><div dir=3D"ltr">On Saturday, January 7, 2017 at 3:1=
5:25 AM UTC+13, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;"><div dir=
=3D"ltr">On Friday, January 6, 2017 at 7:53:33 AM UTC-5, <a>gmis...@gmail.c=
om</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px=
 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-le=
ft-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div></div><div>=
<div>The basic=C2=A0V2 switch I want has a cleaner syntax that is=C2=A0easi=
er to format and use. To me that=C2=A0means it has automatic scopes, case t=
hat break=C2=A0at the end automatically=C2=A0and=C2=A0a structure=C2=A0that=
 minimizes=C2=A0nesting and an excess braces. That seem important=C2=A0to m=
e.</div></div></div></blockquote><div><br>It has a syntax that is fundament=
ally different from <i>anything else in C++</i>. Your definition of &quot;c=
lean&quot; is to not use braces. Well... <i>tough</i>. Curly braces is how =
C++ defines scopes. Pretty much everything that defines a scope uses them: =
functions, classes, if/for/while/do, etc.<br><br>Why should we change somet=
hing that fundamental to how the language looks, just because one person do=
esn&#39;t like using braces for scopes? How does this <i>objectively</i>, o=
r even semi-objectively, improve the language?<br><br>Consistency of the la=
nguage is more important than one user&#39;s comfort<br></div></div></block=
quote><div><br></div><div>I&#39;ve offered=C2=A0my=C2=A0answer=C2=A0to this=
 in another reply.=C2=A0But I as yet=C2=A0don&#39;t=C2=A0see any essential =
consistency lost here yet</div></div></blockquote><div><br>Of course <i>you=
</i> don&#39;t; you have already said that you don&#39;t like curly braces.=
 That doesn&#39;t chance the fact that this would be the first place in C++=
 that defines a scope without braces (or without being limited to a single =
statement).<br><br>You cannot deny that what you have proposed is a novel g=
rammar to C++.<br></div></div></blockquote><div><br></div><div>I=C2=A0don&#=
39;t deny it&#39;s=C2=A0was novel. I am=C2=A0just saying &quot;switch;&quot=
;=C2=A0might not seem=C2=A0as out there=C2=A0if the other suggestions I&#39=
;ve made with it=C2=A0were also enacted and I&#39;ve=C2=A0presented a=C2=A0=
rationale why=C2=A0those=C2=A0suggestions might be=C2=A0motivating to some.=
</div><div><br></div><div>Do you prefer comments to=C2=A0remind people what=
=C2=A0namespace is ending?</div><div>Have you seen people use comments to d=
o that?</div><div><br></div><div>If you have seen comments, that might show=
 other people might prefer=C2=A0an option to=C2=A0check them even if you do=
n&#39;t.</div><div>We don&#39;t know what people prefer until we ask, so I&=
#39;m asking.=C2=A0I&#39;ve seen comments used this way.</div><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; p=
adding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width:=
 1px; border-left-style: solid;"><div dir=3D"ltr"><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left:=
 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border=
-left-style: solid;"><div dir=3D"ltr"><div> but it&#39;s too soon to say. I=
 think=C2=A0we have to=C2=A0see what ideas come forth and how they=C2=A0fit=
=C2=A0together as a whole before judging too harshly.</div></div></blockquo=
te><div><br>I don&#39;t understand what you&#39;re talking about with regar=
d to &quot;what ideas come forth&quot;. If you&#39;re talking about what ot=
her features people might throw into this proposal, those &quot;ideas&quot;=
 would work just as effectively in a `switch` statement that uses standard =
C++ grammar.<br></div></div></blockquote><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204,=
 204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">=
<div>We should also factor in=C2=A0what we might gain here against what we =
might lose. We likely need a new switch to add all the other things we want=
 beyond=C2=A0formatting issues too.</div></div></blockquote><div><br>And wh=
en we get one, <i>it will use curly braces</i>.</div></div></blockquote><di=
v><br></div><div>I hope you are right, but I didn&#39;t like the curly swit=
ches=C2=A0I experimented with=C2=A0so why don&#39;t you propose yours and t=
hen we can compare=C2=A0which formats the best? If=C2=A0yours is=C2=A0bette=
r I&#39;ll happily um switch to it. :)</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/846f9674-66c9-4774-b3b6-7dac43e8ecdf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/846f9674-66c9-4774-b3b6-7dac43e8ecdf=
%40isocpp.org</a>.<br />

------=_Part_856_2043653415.1483718976149--

------=_Part_855_1641150763.1483718976149--

.

--94eb2c1a0b9c4115da05456f6b6d
Content-Type: text/plain; charset=UTF-8

On Fri, Jan 6, 2017 at 1:53 PM, <gmisocpp@gmail.com> wrote:

> I agree with all you've said,  but I want to start small as IMO
whatever the real switch V2 is, it has to have a basic workable structure
that does what switch V1 does in order to graft all that other stuff you
want on to.

I am not convinced you can have it done this way. Form should follow
function, not the other way around.

> What's a basic switch that you'd support look like that does just V1
switch abilities?

Again, the issues that you mentioned are not that important for me. I would
not change switch just because of them.

But since you asked, I want switch v2 as a selection *operator, not a
statement. *So its syntax would an expression syntax.

And, because the existing operator ? gets messy as soon as it gets chained,
perhaps we can improve that one, too? For example, something along these
lines, without explaining the details (chiefly because I am not very sure
about these details):

auto result = ?? query ?= match_1 => result_1 ?= match_2 => { return
result_2; }  ?: default_result;

auto result = ?? conditional => result_1 ?: default_result;

auto result = ?? query ?= match_1 => result_1 ?= match_2=> { return
result_2; } ?? conditional => result_3 ?: default_result;

Obviously, all these forms can be used as statements. Such use, as far as I
can tell, would not have the nuisances you mentioned. Even though I am
pretty sure some people will say this is APL rather than C++.

Cheers,
V.

--
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/CAA7YVg09-UHyG_O%3DNgPkWL0CrQdtb-qC_30GgYhom2nmeLuKxA%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Jan 6, 2017 at 1:53 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:gmisoc=
pp@gmail.com" target=3D"_blank">gmisocpp@gmail.com</a>&gt;</span> wrote:<br=
><div><br></div><div>&gt; I agree with all you&#39;ve said,=C2=A0 but=C2=A0=
I=C2=A0want to start small as IMO whatever=C2=A0the real=C2=A0switch V2 is,=
 it has to=C2=A0have a basic=C2=A0workable structure that does what switch =
V1 does in order=C2=A0to graft all that other stuff you want on to.</div><d=
iv><br></div><div>I am not convinced you can have it done this way. Form sh=
ould follow function, not the other way around.</div><div><br></div><div>&g=
t; What&#39;s a basic switch that you&#39;d support look like that does jus=
t V1 switch abilities?</div><div><br></div><div>Again, the issues that you =
mentioned are not that important for me. I would not change switch just bec=
ause of them.</div><div><br></div><div>But since you asked, I want switch v=
2 as a selection=C2=A0<i>operator, not a statement. </i>So its syntax would=
 an expression syntax.</div><div><br></div><div>And, because the existing o=
perator ? gets messy as soon as it gets chained, perhaps we can improve tha=
t one, too? For example, something along these lines, without explaining th=
e details (chiefly because I am not very sure about these details):</div><d=
iv><br></div><div>auto result =3D ?? query ?=3D match_1 =3D&gt; result_1 ?=
=3D match_2 =3D&gt; { return result_2; } =C2=A0?: default_result;<br></div>=
<div><br></div><div>auto result =3D ?? conditional =3D&gt; result_1=C2=A0?:=
 default_result;<br></div><div><br></div><div>auto result =3D ?? query ?=3D=
 match_1=C2=A0=3D&gt; result_1=C2=A0?=3D match_2=3D&gt; { return result_2; =
}=C2=A0?? conditional =3D&gt; result_3 ?: default_result;<br></div><div><br=
></div><div>Obviously, all these forms can be used as statements. Such use,=
 as far as I can tell, would not have the nuisances you mentioned. Even tho=
ugh I am pretty sure some people will say this is APL rather than C++.<br><=
/div><div><br></div><div>Cheers,</div><div>V.</div></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg09-UHyG_O%3DNgPkWL0CrQdtb-qC_3=
0GgYhom2nmeLuKxA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg09-UHyG_=
O%3DNgPkWL0CrQdtb-qC_30GgYhom2nmeLuKxA%40mail.gmail.com</a>.<br />

--94eb2c1a0b9c4115da05456f6b6d--

.

------=_Part_255_576471120.1483724106999
Content-Type: multipart/alternative;
 boundary="----=_Part_256_1670969631.1483724106999"

------=_Part_256_1670969631.1483724106999
Content-Type: text/plain; charset=UTF-8

On Friday, January 6, 2017 at 11:09:36 AM UTC-5, gmis...@gmail.com wrote:
>
> On Saturday, January 7, 2017 at 4:10:44 AM UTC+13, Nicol Bolas wrote:
>>
>> On Friday, January 6, 2017 at 9:34:07 AM UTC-5, gmis...@gmail.com wrote:
>>>
>>> On Saturday, January 7, 2017 at 3:15:25 AM UTC+13, Nicol Bolas wrote:
>>>>
>>>> On Friday, January 6, 2017 at 7:53:33 AM UTC-5, gmis...@gmail.com
>>>> wrote:
>>>>>
>>>>> The basic V2 switch I want has a cleaner syntax that is easier to
>>>>> format and use. To me that means it has automatic scopes, case that
>>>>> break at the end automatically and a structure that minimizes nesting and
>>>>> an excess braces. That seem important to me.
>>>>>
>>>>
>>>> It has a syntax that is fundamentally different from *anything else in
>>>> C++*. Your definition of "clean" is to not use braces. Well... *tough*.
>>>> Curly braces is how C++ defines scopes. Pretty much everything that defines
>>>> a scope uses them: functions, classes, if/for/while/do, etc.
>>>>
>>>> Why should we change something that fundamental to how the language
>>>> looks, just because one person doesn't like using braces for scopes? How
>>>> does this *objectively*, or even semi-objectively, improve the
>>>> language?
>>>>
>>>> Consistency of the language is more important than one user's comfort
>>>>
>>>
>>> I've offered my answer to this in another reply. But I as yet don't see
>>> any essential consistency lost here yet
>>>
>>
>> Of course *you* don't; you have already said that you don't like curly
>> braces. That doesn't chance the fact that this would be the first place in
>> C++ that defines a scope without braces (or without being limited to a
>> single statement).
>>
>> You cannot deny that what you have proposed is a novel grammar to C++.
>>
>
> I don't deny it's was novel. I am just saying "switch;" might not seem as
> out there if the other suggestions I've made with it were also enacted and
> I've presented a rationale why those suggestions might be motivating to
> some.
>

But why do any of those suggestions *require* not using curly braces as
scopes? We could just as easily provoke this new syntax with this:

switch(blah) break
{
  //Stuff
}

That could allow break-by-default, while still using standard C++ idioms.
Granted, since this is off the top of my head, there could be parsing
issues, so maybe `switch break ()`. Either way, it would invoke the actual
substantive changes you want, without breaking C++'s syntax.

So if you want to justify your "no curly brace switch", you need to do so
by itself, not by trying to piggy-back it onto other functionality.

Do you prefer comments to remind people what namespace is ending?
> Have you seen people use comments to do that?
>

Yes, I've seen that. And ultimately, it's not a significant enough problem
(to the degree that it even is a problem) to be worthy of a language
solution. It is *at most* a language wart, and the committee has far more
important things to be getting on with than removing warts.

If you have seen comments, that might show other people might prefer an
> option to check them even if you don't.
> We don't know what people prefer until we ask, so I'm asking. I've seen
> comments used this way.
>
>
>>
>>
>>> but it's too soon to say. I think we have to see what ideas come forth
>>> and how they fit together as a whole before judging too harshly.
>>>
>>
>> I don't understand what you're talking about with regard to "what ideas
>> come forth". If you're talking about what other features people might throw
>> into this proposal, those "ideas" would work just as effectively in a
>> `switch` statement that uses standard C++ grammar.
>>
>
>
>> We should also factor in what we might gain here against what we might
>>> lose. We likely need a new switch to add all the other things we want
>>> beyond formatting issues too.
>>>
>>
>> And when we get one, *it will use curly braces*.
>>
>
> I hope you are right, but I didn't like the curly switches I experimented
> with so why don't you propose yours and then we can compare which formats
> the best? If yours is better I'll happily um switch to it. :)
>

Because I don't believe that we need to change `switch`'s syntax. Or
rather, I believe that any `switch` fiddling needs to be a comprehensive
part of a pattern matching 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/be4dc514-5aed-4331-95e7-9bb0e4dc47e2%40isocpp.org.

------=_Part_256_1670969631.1483724106999
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, January 6, 2017 at 11:09:36 AM UTC-5, gmis...@g=
mail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">On Saturday, January 7, 2017 at 4:10:44 AM UTC+13, Nicol Bolas wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-lef=
t:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-=
style:solid"><div dir=3D"ltr">On Friday, January 6, 2017 at 9:34:07 AM UTC-=
5, <a>gmis...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr">On Sa=
turday, January 7, 2017 at 3:15:25 AM UTC+13, Nicol Bolas wrote:<blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;b=
order-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:s=
olid"><div dir=3D"ltr">On Friday, January 6, 2017 at 7:53:33 AM UTC-5, <a>g=
mis...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);bor=
der-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div></div><di=
v><div>The basic=C2=A0V2 switch I want has a cleaner syntax that is=C2=A0ea=
sier to format and use. To me that=C2=A0means it has automatic scopes, case=
 that break=C2=A0at the end automatically=C2=A0and=C2=A0a structure=C2=A0th=
at minimizes=C2=A0nesting and an excess braces. That seem important=C2=A0to=
 me.</div></div></div></blockquote><div><br>It has a syntax that is fundame=
ntally different from <i>anything else in C++</i>. Your definition of &quot=
;clean&quot; is to not use braces. Well... <i>tough</i>. Curly braces is ho=
w C++ defines scopes. Pretty much everything that defines a scope uses them=
: functions, classes, if/for/while/do, etc.<br><br>Why should we change som=
ething that fundamental to how the language looks, just because one person =
doesn&#39;t like using braces for scopes? How does this <i>objectively</i>,=
 or even semi-objectively, improve the language?<br><br>Consistency of the =
language is more important than one user&#39;s comfort<br></div></div></blo=
ckquote><div><br></div><div>I&#39;ve offered=C2=A0my=C2=A0answer=C2=A0to th=
is in another reply.=C2=A0But I as yet=C2=A0don&#39;t=C2=A0see any essentia=
l consistency lost here yet</div></div></blockquote><div><br>Of course <i>y=
ou</i> don&#39;t; you have already said that you don&#39;t like curly brace=
s. That doesn&#39;t chance the fact that this would be the first place in C=
++ that defines a scope without braces (or without being limited to a singl=
e statement).<br><br>You cannot deny that what you have proposed is a novel=
 grammar to C++.<br></div></div></blockquote><div><br></div><div>I=C2=A0don=
&#39;t deny it&#39;s=C2=A0was novel. I am=C2=A0just saying &quot;switch;&qu=
ot;=C2=A0might not seem=C2=A0as out there=C2=A0if the other suggestions I&#=
39;ve made with it=C2=A0were also enacted and I&#39;ve=C2=A0presented a=C2=
=A0rationale why=C2=A0those=C2=A0suggestions might be=C2=A0motivating to so=
me.</div></div></blockquote><div><br>But why do any of those suggestions <i=
>require</i> not using curly braces as scopes? We could just as easily prov=
oke this new syntax with this:<br><br><div style=3D"background-color: rgb(2=
50, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; borde=
r-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">switch</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">blah</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">break</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span sty=
le=3D"color: #800;" class=3D"styled-by-prettify">//Stuff</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">}</span></div></code></div><br>Tha=
t could allow break-by-default, while still using standard C++ idioms. Gran=
ted, since this is off the top of my head, there could be parsing issues, s=
o maybe `switch break ()`. Either way, it would invoke the actual substanti=
ve changes you want, without breaking C++&#39;s syntax.<br><br>So if you wa=
nt to justify your &quot;no curly brace switch&quot;, you need to do so by =
itself, not by trying to piggy-back it onto other functionality.<br><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Do yo=
u prefer comments to=C2=A0remind people what=C2=A0namespace is ending?</div=
><div>Have you seen people use comments to do that?</div></div></blockquote=
><div><br>Yes, I&#39;ve seen that. And ultimately, it&#39;s not a significa=
nt enough problem (to the degree that it even is a problem) to be worthy of=
 a language solution. It is <i>at most</i> a language wart, and the committ=
ee has far more important things to be getting on with than removing warts.=
<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div></div><div>If you have seen comments, that might show other people mi=
ght prefer=C2=A0an option to=C2=A0check them even if you don&#39;t.</div><d=
iv>We don&#39;t know what people prefer until we ask, so I&#39;m asking.=C2=
=A0I&#39;ve seen comments used this way.</div><div>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;bo=
rder-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:so=
lid"><div dir=3D"ltr"><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,=
204,204);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><d=
iv> but it&#39;s too soon to say. I think=C2=A0we have to=C2=A0see what ide=
as come forth and how they=C2=A0fit=C2=A0together as a whole before judging=
 too harshly.</div></div></blockquote><div><br>I don&#39;t understand what =
you&#39;re talking about with regard to &quot;what ideas come forth&quot;. =
If you&#39;re talking about what other features people might throw into thi=
s proposal, those &quot;ideas&quot; would work just as effectively in a `sw=
itch` statement that uses standard C++ grammar.<br></div></div></blockquote=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-=
width:1px;border-left-style:solid"><div dir=3D"ltr"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-c=
olor:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div d=
ir=3D"ltr"><div>We should also factor in=C2=A0what we might gain here again=
st what we might lose. We likely need a new switch to add all the other thi=
ngs we want beyond=C2=A0formatting issues too.</div></div></blockquote><div=
><br>And when we get one, <i>it will use curly braces</i>.</div></div></blo=
ckquote><div><br></div><div>I hope you are right, but I didn&#39;t like the=
 curly switches=C2=A0I experimented with=C2=A0so why don&#39;t you propose =
yours and then we can compare=C2=A0which formats the best? If=C2=A0yours is=
=C2=A0better I&#39;ll happily um switch to it. :)</div></div></blockquote><=
div><br>Because I don&#39;t believe that we need to change `switch`&#39;s s=
yntax. Or rather, I believe that any `switch` fiddling needs to be a compre=
hensive part of a pattern matching proposal.<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/be4dc514-5aed-4331-95e7-9bb0e4dc47e2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/be4dc514-5aed-4331-95e7-9bb0e4dc47e2=
%40isocpp.org</a>.<br />

------=_Part_256_1670969631.1483724106999--

------=_Part_255_576471120.1483724106999--

.

--94eb2c074a042564480545714c9e
Content-Type: text/plain; charset=UTF-8

A problem demonstrated here is that trying to do too much in one proposal
(so far as we can call this that) is likely to fail, as the discussion
becomes bogged down in focussing on one thing, often relatively cosmetic,
which the proposer thought was something handy to do 'on the side' but
which ends up eclipsing the main, functional changes (not that I like those
much either)

Also:

> I hope you are right, but I didn't like the curly switches I experimented
> with so why don't you propose yours and then we can compare which formats
> the best? If yours is better I'll happily um switch to it. :)


The onus is on you to prove that your idea is viable or useful, not on
others to provide better alternatives.

--
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/CACGiwhFS20xH65UVGG5Rm66G3nPEPxwOCsp_1pNVW1kOgXJNEw%40mail.gmail.com.

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

<div dir=3D"ltr"><div>A problem demonstrated here is that trying to do too =
much in one proposal (so far as we can call this that) is likely to fail, a=
s the discussion becomes bogged down in focussing on one thing, often relat=
ively cosmetic, which the proposer thought was something handy to do &#39;o=
n the side&#39; but which ends up eclipsing the main, functional changes (n=
ot that I like those much either)<br><br></div><div>Also:<br><blockquote st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex" class=3D"gmail_quote"><span class=3D"gmail-im">I hope you are=
 right, but I didn&#39;t like the curly=20
switches=C2=A0I experimented with=C2=A0so why don&#39;t you propose yours a=
nd then we=20
can compare=C2=A0which formats the best? If=C2=A0yours is=C2=A0better I&#39=
;ll happily um=20
switch to it. :)</span>=C2=A0</blockquote><div>=C2=A0</div></div>The onus i=
s on you to prove that your idea is viable or useful, not on others to prov=
ide better alternatives.<br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhFS20xH65UVGG5Rm66G3nPEPxwOCsp_=
1pNVW1kOgXJNEw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFS20xH65UV=
GG5Rm66G3nPEPxwOCsp_1pNVW1kOgXJNEw%40mail.gmail.com</a>.<br />

--94eb2c074a042564480545714c9e--

.

--001a11405e06726b1905457156e6
Content-Type: text/plain; charset=UTF-8

2017-01-06 17:09 GMT+01:00 <gmisocpp@gmail.com>:

>
>
> On Saturday, January 7, 2017 at 4:10:44 AM UTC+13, Nicol Bolas wrote:
>>
>> On Friday, January 6, 2017 at 9:34:07 AM UTC-5, gmis...@gmail.com wrote:
>>>
>>> On Saturday, January 7, 2017 at 3:15:25 AM UTC+13, Nicol Bolas wrote:
>>>>
>>>> On Friday, January 6, 2017 at 7:53:33 AM UTC-5, gmis...@gmail.com
>>>> wrote:
>>>>>
>>>>> The basic V2 switch I want has a cleaner syntax that is easier to
>>>>> format and use. To me that means it has automatic scopes, case that
>>>>> break at the end automatically and a structure that minimizes nesting and
>>>>> an excess braces. That seem important to me.
>>>>>
>>>>
>>>> It has a syntax that is fundamentally different from *anything else in
>>>> C++*. Your definition of "clean" is to not use braces. Well... *tough*.
>>>> Curly braces is how C++ defines scopes. Pretty much everything that defines
>>>> a scope uses them: functions, classes, if/for/while/do, etc.
>>>>
>>>> Why should we change something that fundamental to how the language
>>>> looks, just because one person doesn't like using braces for scopes? How
>>>> does this *objectively*, or even semi-objectively, improve the
>>>> language?
>>>>
>>>> Consistency of the language is more important than one user's comfort
>>>>
>>>
>>> I've offered my answer to this in another reply. But I as yet don't see
>>> any essential consistency lost here yet
>>>
>>
>> Of course *you* don't; you have already said that you don't like curly
>> braces. That doesn't chance the fact that this would be the first place in
>> C++ that defines a scope without braces (or without being limited to a
>> single statement).
>>
>> You cannot deny that what you have proposed is a novel grammar to C++.
>>
>
> I don't deny it's was novel. I am just saying "switch;" might not seem as
> out there if the other suggestions I've made with it were also enacted and
> I've presented a rationale why those suggestions might be motivating to
> some.
>
> Do you prefer comments to remind people what namespace is ending?
>

My namespaces end with

} // ns

or

}}} // ns

for multiple namespaces

so not really something that has commenting issues (it's just a note
saying: yes this is the end of namespaces and in remote case you want to
bother to know its name(s) go check above...). In this case the

namespace a::b::c {
} // ns

notation is more than enough readability improvement for my taste.


> Have you seen people use comments to do that?
>
> If you have seen comments, that might show other people might prefer an
> option to check them even if you don't.
> We don't know what people prefer until we ask, so I'm asking. I've seen
> comments used this way.
>

Your switch approach would be alien to my eyes in C++ (less consistency)
and extending that inconsistency to other parts of the language like
namespaces (where suddenly you'd have two ways of writing something so
simple) would be even more annoying to  read as it would still differ from
if, for, while, functions, classes... Well more or less everything else
that requires a scope.

Regards,
Domen

--
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/CAKgx6BKU%2BUZKL9s9fE0nzvcDFxNECBt_fjZ-SqtC23LCEsHRQQ%40mail.gmail.com.

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

<div dir=3D"ltr">2017-01-06 17:09 GMT+01:00  <span dir=3D"ltr">&lt;<a href=
=3D"mailto:gmisocpp@gmail.com" target=3D"_blank">gmisocpp@gmail.com</a>&gt;=
</span>:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><br><br>On Saturday=
, January 7, 2017 at 4:10:44 AM UTC+13, Nicol Bolas wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-=
left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">=
<div dir=3D"ltr">On Friday, January 6, 2017 at 9:34:07 AM UTC-5, <a>gmis...=
@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-le=
ft-width:1px;border-left-style:solid"><div dir=3D"ltr">On Saturday, January=
 7, 2017 at 3:15:25 AM UTC+13, Nicol Bolas wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-colo=
r:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir=
=3D"ltr">On Friday, January 6, 2017 at 7:53:33 AM UTC-5, <a>gmis...@gmail.c=
om</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid"><div dir=3D"ltr"><div></div><div><div>The bas=
ic=C2=A0V2 switch I want has a cleaner syntax that is=C2=A0easier to format=
 and use. To me that=C2=A0means it has automatic scopes, case that break=C2=
=A0at the end automatically=C2=A0and=C2=A0a structure=C2=A0that minimizes=
=C2=A0nesting and an excess braces. That seem important=C2=A0to me.</div></=
div></div></blockquote><div><br>It has a syntax that is fundamentally diffe=
rent from <i>anything else in C++</i>. Your definition of &quot;clean&quot;=
 is to not use braces. Well... <i>tough</i>. Curly braces is how C++ define=
s scopes. Pretty much everything that defines a scope uses them: functions,=
 classes, if/for/while/do, etc.<br><br>Why should we change something that =
fundamental to how the language looks, just because one person doesn&#39;t =
like using braces for scopes? How does this <i>objectively</i>, or even sem=
i-objectively, improve the language?<br><br>Consistency of the language is =
more important than one user&#39;s comfort<br></div></div></blockquote><div=
><br></div><div>I&#39;ve offered=C2=A0my=C2=A0answer=C2=A0to this in anothe=
r reply.=C2=A0But I as yet=C2=A0don&#39;t=C2=A0see any essential consistenc=
y lost here yet</div></div></blockquote><div><br>Of course <i>you</i> don&#=
39;t; you have already said that you don&#39;t like curly braces. That does=
n&#39;t chance the fact that this would be the first place in C++ that defi=
nes a scope without braces (or without being limited to a single statement)=
..<br><br>You cannot deny that what you have proposed is a novel grammar to =
C++.<br></div></div></blockquote><div><br></div></span><div>I=C2=A0don&#39;=
t deny it&#39;s=C2=A0was novel. I am=C2=A0just saying &quot;switch;&quot;=
=C2=A0might not seem=C2=A0as out there=C2=A0if the other suggestions I&#39;=
ve made with it=C2=A0were also enacted and I&#39;ve=C2=A0presented a=C2=A0r=
ationale why=C2=A0those=C2=A0suggestions might be=C2=A0motivating to some.<=
/div><div><br></div><div>Do you prefer comments to=C2=A0remind people what=
=C2=A0namespace is ending?</div></div></blockquote><div><br></div><div>My n=
amespaces end with<br><br>} // ns<br><br></div><div>or <br><br></div><div>}=
}} // ns<br><br></div><div>for multiple namespaces<br></div><div><br></div>=
<div>so not really something that has commenting issues (it&#39;s just a no=
te saying: yes this is the end of namespaces and in remote case you want to=
 bother to know its name(s) go check above...). In this case the<br><br></d=
iv><div>namespace a::b::c {<br></div><div>} // ns<br></div><div><br></div><=
div>notation is more than enough readability improvement for my taste.<br><=
/div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=
Have you seen people use comments to do that?</div><div><br></div><div>If y=
ou have seen comments, that might show other people might prefer=C2=A0an op=
tion to=C2=A0check them even if you don&#39;t.</div><div>We don&#39;t know =
what people prefer until we ask, so I&#39;m asking.=C2=A0I&#39;ve seen comm=
ents used this way.</div></div></blockquote><div><br></div><div>Your switch=
 approach would be alien to my eyes in C++ (less consistency) and extending=
 that inconsistency to other parts of the language like namespaces (where s=
uddenly you&#39;d have two ways of writing something so simple) would be ev=
en more annoying to=C2=A0 read as it would still differ from if, for, while=
, functions, classes... Well more or less everything else that requires a s=
cope.</div><div><br></div><div>Regards,<br></div><div>Domen<br></div></div>=
</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKgx6BKU%2BUZKL9s9fE0nzvcDFxNECBt_fj=
Z-SqtC23LCEsHRQQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6BKU%2BUZK=
L9s9fE0nzvcDFxNECBt_fjZ-SqtC23LCEsHRQQ%40mail.gmail.com</a>.<br />

--001a11405e06726b1905457156e6--

.

------=_Part_1413_1586502578.1483761374082
Content-Type: multipart/alternative;
 boundary="----=_Part_1414_1542293269.1483761374083"

------=_Part_1414_1542293269.1483761374083
Content-Type: text/plain; charset=UTF-8



On Saturday, January 7, 2017 at 7:36:37 AM UTC+13, D. B. wrote:
>
> A problem demonstrated here is that trying to do too much in one proposal
> (so far as we can call this that) is likely to fail, as the discussion
> becomes bogged down in focussing on one thing, often relatively cosmetic,
> which the proposer thought was something handy to do 'on the side' but
> which ends up eclipsing the main, functional changes (not that I like those
> much either)
>

I'm not trying to do too much. I posted purely on defining what a basic v2
switch might look like that does what the current switch
does, whilst fixing it's formatting issues and most basic problems. That's
not too much.

In fact one of the first comments I had was that it was not too
much, rather it was not enough. I directed that to another thread
precisely so things didn't get too much.

If think it would be good to have base switch structure that people can
coalesce ideas around. You call it cosmetics but syntax is important. In
any case the syntax and basics is what I'm focused on here. If you are
going beyond that here, you're solving more than I'm looking at and that
might be where too much will come in.
But what I'm trying to focus on is the basics.


> Also:
>
>> I hope you are right, but I didn't like the curly switches I experimented
>> with so why don't you propose yours and then we can compare which formats
>> the best? If yours is better I'll happily um switch to it. :)
>
>
> The onus is on you to prove that your idea is viable or useful, not on
> others to provide better alternatives.
>

Answering questions here IS me honouring that onus. I've already fiddled
with ideas with braces in and I decided braces were the source of the
formatting/verbosity problem. Since you disagree with that essence and
given that braces are a pretty simple to explain, the onus is on you now to
present how you feel braces work better.

But you aren't doing that. Instead you are
stating without presentation that braces must stay or we'll have
inconsistency. That hard to fight when you also seem to be contending
that any discussion to the contrary on braces (like me suggesting that
removing braces from other constructs like namespaces might lessen the
notion that "switch;" is an oddity) is complicating the discussion "too
much".

That seems an odd bind place on someone but in any case I don't agree
because my statements were directly related to the basic idea I'm trying to
solve which is one of syntax and cohesion for switch and there is nothing
complicated in the ideas I've put out they are just supporting comments for
my core point.

You seem to be having things both way there by putting onus on me to
explain why no braces are good then saying it's too much when I do, without
taking any onus on yourself to present anything at all.

Anyway, keeping with my onus, I take from here:
https://github.com/solodon4/Mach7
this example:

void print(const boost::variant<double,float,int>& v)
{
    var<double> d; var<float> f; var<int> n;
    match(v)
    {
      case(C<double>(d))
          cout << "double " << d << endl; break;
      case(C<float> (f))
           cout << "float  " << f << endl; break;
      case(C<int>   (n))
           cout << "int    " << n << endl; break;
    }
    endmatch
}

This doesn't use braces in the case statements and I don't find
it shocking. If it were standardized that way I'd be ok. So I don't
see braces being the big deal it's made out to be. Perhaps people just need
to get used to it. Hopefully this discussion assists that even if it just
tests it.

Anyway, that's all my views on no braces. If somebody is disagreeing, show
me your braces. :)
I think this post addresses Nicols questions too.


--
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/f6eec74f-2c9a-423e-8371-71e44800e41c%40isocpp.org.

------=_Part_1414_1542293269.1483761374083
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, January 7, 2017 at 7:36:37 AM UTC+13,=
 D. B. wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px=
 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-le=
ft-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>A problem d=
emonstrated here is that trying to do too much in one proposal (so far as w=
e can call this that) is likely to fail, as the discussion becomes bogged d=
own in focussing on one thing, often relatively cosmetic, which the propose=
r thought was something handy to do &#39;on the side&#39; but which ends up=
 eclipsing the main, functional changes (not that I like those much either)=
<br></div></div></blockquote><div><br></div><div>I&#39;m not trying to do t=
oo much.=C2=A0I posted=C2=A0purely=C2=A0on=C2=A0defining what=C2=A0a basic =
v2 switch=C2=A0might look like=C2=A0that does=C2=A0what the current switch =
does,=C2=A0whilst=C2=A0fixing=C2=A0it&#39;s formatting issues and most basi=
c problems. That&#39;s not too much.</div><div><br></div><div>In fact one=
=C2=A0of the first comments I had was that=C2=A0it=C2=A0was not too much,=
=C2=A0rather it was=C2=A0not enough.=C2=A0I=C2=A0directed that to another t=
hread precisely=C2=A0so things didn&#39;t get too much.</div><div><br></div=
><div>If think it would be=C2=A0good=C2=A0to have=C2=A0base=C2=A0switch str=
ucture that people can coalesce=C2=A0ideas around.=C2=A0You call it=C2=A0co=
smetics=C2=A0but=C2=A0syntax is important. In any case=C2=A0the syntax and =
basics is what I&#39;m focused on=C2=A0here. If you are going beyond that h=
ere, you&#39;re solving=C2=A0more than=C2=A0I&#39;m looking at and that mig=
ht be where=C2=A0too much will come in.</div><div>But what I&#39;m trying t=
o focus on is the basics.</div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-col=
or: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">=
<div dir=3D"ltr"><div><br></div><div>Also:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-col=
or: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">=
<span>I hope you are right, but I didn&#39;t like the curly=20
switches=C2=A0I experimented with=C2=A0so why don&#39;t you propose yours a=
nd then we=20
can compare=C2=A0which formats the best? If=C2=A0yours is=C2=A0better I&#39=
;ll happily um=20
switch to it. :)</span>=C2=A0</blockquote><div>=C2=A0</div></div>The onus i=
s on you to prove that your idea is viable or useful, not on others to prov=
ide better alternatives.<br></div></blockquote><div><br></div><div><div>Ans=
wering questions=C2=A0here IS me honouring that onus.=C2=A0I&#39;ve=C2=A0al=
ready=C2=A0fiddled with ideas=C2=A0with braces in and=C2=A0I decided=C2=A0b=
races=C2=A0were the source of the formatting/verbosity problem.=C2=A0Since =
you=C2=A0disagree with that=C2=A0essence=C2=A0and given that=C2=A0braces ar=
e a=C2=A0pretty simple=C2=A0to explain,=C2=A0the onus=C2=A0is on you=C2=A0n=
ow to present how=C2=A0you feel=C2=A0braces=C2=A0work better.</div><div><br=
></div><div>But you aren&#39;t doing that. Instead=C2=A0you are stating=C2=
=A0without=C2=A0presentation=C2=A0that=C2=A0braces must stay or we&#39;ll h=
ave inconsistency.=C2=A0That=C2=A0hard to fight when you also seem=C2=A0to =
be=C2=A0contending that=C2=A0any=C2=A0discussion to the contrary on braces =
(like me=C2=A0suggesting=C2=A0that removing braces=C2=A0from other construc=
ts like namespaces=C2=A0might lessen the notion that &quot;switch;&quot;=C2=
=A0is an oddity)=C2=A0is complicating the discussion &quot;too much&quot;.<=
/div><div><br></div><div>That seems an odd bind place on someone but in any=
 case=C2=A0I don&#39;t agree because my statements=C2=A0were directly relat=
ed to=C2=A0the=C2=A0basic idea I&#39;m trying to solve which is one of synt=
ax and cohesion for switch and=C2=A0there is nothing complicated in the ide=
as I&#39;ve put out they are just supporting comments for my core point.</d=
iv><div><br></div><div>You seem to be having things both way there=C2=A0by =
putting onus on me to explain why no braces are good then saying it&#39;s t=
oo much when I do, without taking=C2=A0any=C2=A0onus on yourself to present=
 anything at all.</div><div><br></div><div>Anyway,=C2=A0keeping with my onu=
s, I take from here: <a href=3D"https://github.com/solodon4/Mach7">https://=
github.com/solodon4/Mach7</a></div><div>this example:</div><div><br></div><=
div>void print(const boost::variant&lt;double,float,int&gt;&amp; v)<br>{<br=
>=C2=A0=C2=A0=C2=A0 var&lt;double&gt; d; var&lt;float&gt; f; var&lt;int&gt;=
 n;</div><div>=C2=A0=C2=A0=C2=A0 match(v)<br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 case(C&lt;double&gt;(d))</div><div>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cout &lt;&lt; &quot;double &quot; &=
lt;&lt; d &lt;&lt; endl; break;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case(C&lt=
;float&gt; (f))</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 cout &lt;&lt; &quot;float=C2=A0 &quot; &lt;&lt; f &lt;&lt; end=
l; break;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case(C&lt;int&gt;=C2=A0=C2=A0 (=
n))</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
cout &lt;&lt; &quot;int=C2=A0=C2=A0=C2=A0 &quot; &lt;&lt; n &lt;&lt; endl; =
break;<br>=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=A0 endmatch<br>}</div><di=
v><br></div><div>This=C2=A0doesn&#39;t use braces in the case statements an=
d I don&#39;t find it=C2=A0shocking. If it were standardized that way=C2=A0=
I&#39;d=C2=A0be ok.=C2=A0So I don&#39;t see=C2=A0braces=C2=A0being the big =
deal it&#39;s made out to be. Perhaps people=C2=A0just need to get used to =
it.=C2=A0Hopefully this discussion assists that even if it just tests it.</=
div><div><br></div></div><div><div><div>Anyway, that&#39;s all my views on =
no braces. If somebody is disagreeing, show me your braces. :)</div><div>I =
think this=C2=A0post addresses Nicols questions too.</div></div><div><div>=
=C2=A0</div></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f6eec74f-2c9a-423e-8371-71e44800e41c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f6eec74f-2c9a-423e-8371-71e44800e41c=
%40isocpp.org</a>.<br />

------=_Part_1414_1542293269.1483761374083--

------=_Part_1413_1586502578.1483761374082--

.

------=_Part_1399_1302558612.1483761727528
Content-Type: multipart/alternative;
 boundary="----=_Part_1400_1604293527.1483761727529"

------=_Part_1400_1604293527.1483761727529
Content-Type: text/plain; charset=UTF-8



On Saturday, January 7, 2017 at 5:22:08 AM UTC+13, Viacheslav Usov wrote:
>
> On Fri, Jan 6, 2017 at 1:53 PM, <gmis...@gmail.com <javascript:>> wrote:
>
> > I agree with all you've said,  but I want to start small as IMO
> whatever the real switch V2 is, it has to have a basic workable structure
> that does what switch V1 does in order to graft all that other stuff you
> want on to.
>
> I am not convinced you can have it done this way. Form should follow
> function, not the other way around.
>

I think you might be right here but I can't bite off that much function :)


>
> > What's a basic switch that you'd support look like that does just V1
> switch abilities?
>
> Again, the issues that you mentioned are not that important for me. I
> would not change switch just because of them.
>
> But since you asked, I want switch v2 as a selection *operator, not a
> statement. *So its syntax would an expression syntax.
>
> And, because the existing operator ? gets messy as soon as it gets
> chained, perhaps we can improve that one, too? For example, something along
> these lines, without explaining the details (chiefly because I am not very
> sure about these details):
>
> auto result = ?? query ?= match_1 => result_1 ?= match_2 => { return
> result_2; }  ?: default_result;
>
> auto result = ?? conditional => result_1 ?: default_result;
>
> auto result = ?? query ?= match_1 => result_1 ?= match_2=> { return
> result_2; } ?? conditional => result_3 ?: default_result;
>
> Obviously, all these forms can be used as statements. Such use, as far as
> I can tell, would not have the nuisances you mentioned. Even though I am
> pretty sure some people will say this is APL rather than C++.
>
>
Yes I'm surprised you haven't attracted the 'its not C++' ire with that. I
got it just for dropping some braces. ha ha



> Cheers,
> V.
>

--
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/d680ef30-ff75-4221-8e03-2756da2c7d19%40isocpp.org.

------=_Part_1400_1604293527.1483761727529
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, January 7, 2017 at 5:22:08 AM UTC+13,=
 Viacheslav Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204);=
 border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><=
div class=3D"gmail_quote">On Fri, Jan 6, 2017 at 1:53 PM,  <span dir=3D"ltr=
">&lt;<a onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onc=
lick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"javascript:=
" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"BtoIs_xjDAAJ"=
>gmis...@gmail.com</a>&gt;</span> wrote:<br><div><br></div><div>&gt; I agre=
e with all you&#39;ve said,=C2=A0 but=C2=A0I=C2=A0want to start small as IM=
O whatever=C2=A0the real=C2=A0switch V2 is, it has to=C2=A0have a basic=C2=
=A0workable structure that does what switch V1 does in order=C2=A0to graft =
all that other stuff you want on to.</div><div><br></div><div>I am not conv=
inced you can have it done this way. Form should follow function, not the o=
ther way around.</div></div></div></div></blockquote><div><br></div><div>I =
think you might be right here but I can&#39;t bite=C2=A0off that much funct=
ion :)</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204,=
 204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote"><div><br></div><div>&gt; What&#39;s a basic=
 switch that you&#39;d support look like that does just V1 switch abilities=
?</div><div><br></div><div>Again, the issues that you mentioned are not tha=
t important for me. I would not change switch just because of them.</div><d=
iv><br></div><div>But since you asked, I want switch v2 as a selection=C2=
=A0<i>operator, not a statement. </i>So its syntax would an expression synt=
ax.</div><div><br></div><div>And, because the existing operator ? gets mess=
y as soon as it gets chained, perhaps we can improve that one, too? For exa=
mple, something along these lines, without explaining the details (chiefly =
because I am not very sure about these details):</div><div><br></div><div>a=
uto result =3D ?? query ?=3D match_1 =3D&gt; result_1 ?=3D match_2 =3D&gt; =
{ return result_2; } =C2=A0?: default_result;<br></div><div><br></div><div>=
auto result =3D ?? conditional =3D&gt; result_1=C2=A0?: default_result;<br>=
</div><div><br></div><div>auto result =3D ?? query ?=3D match_1=C2=A0=3D&gt=
; result_1=C2=A0?=3D match_2=3D&gt; { return result_2; }=C2=A0?? conditiona=
l =3D&gt; result_3 ?: default_result;<br></div><div><br></div><div>Obviousl=
y, all these forms can be used as statements. Such use, as far as I can tel=
l, would not have the nuisances you mentioned. Even though I am pretty sure=
 some people will say this is APL rather than C++.<br></div><div><br></div>=
</div></div></div></blockquote><div><br></div><div>Yes I&#39;m surprised yo=
u haven&#39;t attracted the &#39;its not C++&#39; ire with that. I got it j=
ust for dropping some braces. ha ha</div><div><br></div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding=
-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; =
border-left-style: solid;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"=
><div></div><div>Cheers,</div><div>V.</div></div></div></div>
</blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d680ef30-ff75-4221-8e03-2756da2c7d19%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d680ef30-ff75-4221-8e03-2756da2c7d19=
%40isocpp.org</a>.<br />

------=_Part_1400_1604293527.1483761727529--

------=_Part_1399_1302558612.1483761727528--

.

------=_Part_1422_602931699.1483764264846
Content-Type: multipart/alternative;
 boundary="----=_Part_1423_359199165.1483764264846"

------=_Part_1423_359199165.1483764264846
Content-Type: text/plain; charset=UTF-8

On Friday, January 6, 2017 at 10:56:14 PM UTC-5, gmis...@gmail.com wrote:
>
> On Saturday, January 7, 2017 at 7:36:37 AM UTC+13, D. B. wrote:
>>
>> A problem demonstrated here is that trying to do too much in one proposal
>> (so far as we can call this that) is likely to fail, as the discussion
>> becomes bogged down in focussing on one thing, often relatively cosmetic,
>> which the proposer thought was something handy to do 'on the side' but
>> which ends up eclipsing the main, functional changes (not that I like those
>> much either)
>>
>
> I'm not trying to do too much. I posted purely on defining what a basic v2
> switch might look like that does what the current switch
> does, whilst fixing it's formatting issues and most basic problems. That's
> not too much.
>
> In fact one of the first comments I had was that it was not too
> much, rather it was not enough. I directed that to another thread
> precisely so things didn't get too much.
>
> If think it would be good to have base switch structure that people can
> coalesce ideas around.
>

Why? We don't need a new switch structure. People "can coalesce ideas
around" the existing structure just fine. Or if there need to be tweaks to
make some actual feature available, then we can have tweaks then, when it
is *justified*.

We do not need an entire new switch infrastructure just to add new features
to switch.

You call it cosmetics but syntax is important. In any case the syntax and
> basics is what I'm focused on here. If you are going beyond that here,
> you're solving more than I'm looking at and that might be where too much
> will come in.
> But what I'm trying to focus on is the basics.
>
> Also:
>>
>>> I hope you are right, but I didn't like the curly switches I
>>> experimented with so why don't you propose yours and then we can
>>> compare which formats the best? If yours is better I'll happily um switch
>>> to it. :)
>>
>>
>> The onus is on you to prove that your idea is viable or useful, not on
>> others to provide better alternatives.
>>
>
> Answering questions here IS me honouring that onus. I've already fiddled
> with ideas with braces in and I decided braces were the source of the
> formatting/verbosity problem. Since you disagree with that essence and
> given that braces are a pretty simple to explain, the onus is on you now to
> present how you feel braces work better.
>

No, it isn't.

You have declared that there is a "formatting/verbosity problem" with the
current switch syntax. Yet you have provided zero evidence that this
problem *objectively exists*. The argument you have provided for this idea
is essentially you showing a piece of code, then declaring that it is badly
formatted under the current brace-based syntax. Actually no, you haven't
even done that; you've simply stated that the current syntax is bad,
without showing even *one example* of code where the current syntax
actually is bad.

As far as I'm concerned, I remain entirely unconvinced that this "problem"
with braces actually *exists*. That is, I believe that this "problem"
afflicts a very small number of users and that the rest of us consider the
status quo sufficiently functional that no change is warranted.

If you're proposing a change, and you can't convince other people that the
problem you're trying to solve even *exists*, then the onus remains on you
to provide adequate motivation for it.

This is the fundamental problem with cosmetic syntactical alterations like
these. Cosmetic issues are the most subjective changes. As such, they
usually lack any objective motivation for them. So it's very difficult to
convince other people that the problem you're trying to solve exists, let
alone is sufficiently problematic to be worth actually solving.

But you aren't doing that. Instead you are
> stating without presentation that braces must stay or we'll have
> inconsistency. That hard to fight when you also seem to be contending
> that any discussion to the contrary on braces (like me suggesting that
> removing braces from other constructs like namespaces might lessen the
> notion that "switch;" is an oddity) is complicating the discussion "too
> much".
>

Allow me to present my view of this conversation thus far:

*You:* Let's introduce a switch statement that gets rid of braces.

*Us:* ... why?

*You:* Because I think braces cause a "formatting/verbosity problem".

*Us:* Well, we don't agree that this is the case. Do you have any other
reason for wanting this?

*You:* Well, I guess people could graft other things onto my syntax too.
But why would you be against it?

*Us:* Because your new brace-less switch syntax will be fundamentally
inconsistent with the rest of the language.

*You:* ...sure, but we can fix that by making *more parts* of the language
inconsistent too!

*Us:* :facepalm:

Anyway, keeping with my onus, I take from here:
> https://github.com/solodon4/Mach7
> this example:
>
> void print(const boost::variant<double,float,int>& v)
> {
>     var<double> d; var<float> f; var<int> n;
>     match(v)
>     {
>       case(C<double>(d))
>           cout << "double " << d << endl; break;
>       case(C<float> (f))
>            cout << "float  " << f << endl; break;
>       case(C<int>   (n))
>            cout << "int    " << n << endl; break;
>     }
>     endmatch
> }
>
> This doesn't use braces in the case statements and I don't find
> it shocking.
>

C++ doesn't require the use of braces *in case statements*. Ignoring that
the `case`s are not constant expressions and the use of the non-standard
`match/endmatch` syntax (note that `endmatch` is there because it feeds
into the macro magic, not because the developer actually wanted it), this
is perfectly legitimate C++ code now.

C++ requires the use of braces with `switch` (if you want to have more than
one statement). We are talking about how your syntax lacks *any braces*.

So I fail to see how this addresses anything people have said about 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d0632288-462d-4995-8b35-bbcbad67b5d7%40isocpp.org.

------=_Part_1423_359199165.1483764264846
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, January 6, 2017 at 10:56:14 PM UTC-5, gmis...@g=
mail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">On Saturday, January 7, 2017 at 7:36:37 AM UTC+13, D. B. wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;=
border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:=
solid"><div dir=3D"ltr"><div>A problem demonstrated here is that trying to =
do too much in one proposal (so far as we can call this that) is likely to =
fail, as the discussion becomes bogged down in focussing on one thing, ofte=
n relatively cosmetic, which the proposer thought was something handy to do=
 &#39;on the side&#39; but which ends up eclipsing the main, functional cha=
nges (not that I like those much either)<br></div></div></blockquote><div><=
br></div><div>I&#39;m not trying to do too much.=C2=A0I posted=C2=A0purely=
=C2=A0on=C2=A0defining what=C2=A0a basic v2 switch=C2=A0might look like=C2=
=A0that does=C2=A0what the current switch does,=C2=A0whilst=C2=A0fixing=C2=
=A0it&#39;s formatting issues and most basic problems. That&#39;s not too m=
uch.</div><div><br></div><div>In fact one=C2=A0of the first comments I had =
was that=C2=A0it=C2=A0was not too much,=C2=A0rather it was=C2=A0not enough.=
=C2=A0I=C2=A0directed that to another thread precisely=C2=A0so things didn&=
#39;t get too much.</div><div><br></div><div>If think it would be=C2=A0good=
=C2=A0to have=C2=A0base=C2=A0switch structure that people can coalesce=C2=
=A0ideas around.</div></div></blockquote><div><br>Why? We don&#39;t need a =
new switch structure. People &quot;can coalesce=C2=A0ideas around&quot; the=
 existing structure just fine. Or if there need to be tweaks to make some a=
ctual feature available, then we can have tweaks then, when it is <i>justif=
ied</i>.<br><br>We do not need an entire new switch infrastructure just to =
add new features to switch.<br><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><div>You call it=C2=A0cosmetics=C2=A0but=C2=A0s=
yntax is important. In any case=C2=A0the syntax and basics is what I&#39;m =
focused on=C2=A0here. If you are going beyond that here, you&#39;re solving=
=C2=A0more than=C2=A0I&#39;m looking at and that might be where=C2=A0too mu=
ch will come in.</div><div>But what I&#39;m trying to focus on is the basic=
s.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-=
left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div></div><div>Al=
so:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;b=
order-left-style:solid"><span>I hope you are right, but I didn&#39;t like t=
he curly=20
switches=C2=A0I experimented with=C2=A0so why don&#39;t you propose yours a=
nd then we=20
can compare=C2=A0which formats the best? If=C2=A0yours is=C2=A0better I&#39=
;ll happily um=20
switch to it. :)</span>=C2=A0</blockquote><div>=C2=A0</div></div>The onus i=
s on you to prove that your idea is viable or useful, not on others to prov=
ide better alternatives.<br></div></blockquote><div><br></div><div><div>Ans=
wering questions=C2=A0here IS me honouring that onus.=C2=A0I&#39;ve=C2=A0al=
ready=C2=A0fiddled with ideas=C2=A0with braces in and=C2=A0I decided=C2=A0b=
races=C2=A0were the source of the formatting/verbosity problem.=C2=A0Since =
you=C2=A0disagree with that=C2=A0essence=C2=A0and given that=C2=A0braces ar=
e a=C2=A0pretty simple=C2=A0to explain,=C2=A0the onus=C2=A0is on you=C2=A0n=
ow to present how=C2=A0you feel=C2=A0braces=C2=A0work better.</div></div></=
div></blockquote><div><br>No, it isn&#39;t.<br><br>You have declared that t=
here is a &quot;formatting/verbosity problem&quot; with the current switch =
syntax. Yet you have provided zero evidence that this problem <i>objectivel=
y exists</i>. The argument you have provided for this idea is essentially y=
ou showing a piece of code, then declaring that it is badly formatted under=
 the current brace-based syntax. Actually no, you haven&#39;t even done tha=
t; you&#39;ve simply stated that the current syntax is bad, without showing=
 even <i>one example</i> of code where the current syntax actually is bad.<=
br><br>As far as I&#39;m concerned, I remain entirely unconvinced that this=
 &quot;problem&quot; with braces actually <i>exists</i>. That is, I believe=
 that this &quot;problem&quot; afflicts a very small number of users and th=
at the rest of us consider the status quo sufficiently functional that no c=
hange is warranted.<br><br>If you&#39;re proposing a change, and you can&#3=
9;t convince other people that the problem you&#39;re trying to solve even =
<i>exists</i>, then the onus remains on you to provide adequate motivation =
for it.<br><br>This is the fundamental problem with cosmetic syntactical al=
terations like these. Cosmetic issues are the most subjective changes. As s=
uch, they usually lack any objective motivation for them. So it&#39;s very =
difficult to convince other people that the problem you&#39;re trying to so=
lve exists, let alone is sufficiently problematic to be worth actually solv=
ing.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div><div></div><div>But you aren&#39;t doing that. Instead=C2=A0you a=
re stating=C2=A0without=C2=A0presentation=C2=A0<wbr>that=C2=A0braces must s=
tay or we&#39;ll have inconsistency.=C2=A0That=C2=A0hard to fight when you =
also seem=C2=A0to be=C2=A0contending that=C2=A0any=C2=A0discussion to the c=
ontrary on braces (like me=C2=A0suggesting=C2=A0that removing braces=C2=A0f=
rom other constructs like namespaces=C2=A0might lessen the notion that &quo=
t;switch;&quot;=C2=A0is an oddity)=C2=A0is complicating the discussion &quo=
t;too much&quot;.</div></div></div></blockquote><div><br>Allow me to presen=
t my view of this conversation thus far:<br><br><u><b>You:</b></u> Let&#39;=
s introduce a switch statement that gets rid of braces.<br><br><b><u>Us:</u=
></b> ... why?<br><br><b><u>You:</u></b> Because I think braces cause a &qu=
ot;formatting/verbosity problem&quot;.<br><br><u><b>Us:</b></u> Well, we do=
n&#39;t agree that this is the case. Do you have any other reason for wanti=
ng this?<br><br><b><u>You:</u></b> Well, I guess people could graft other t=
hings onto my syntax too. But why would you be against it?<br><br><b><u>Us:=
</u></b> Because your new brace-less switch syntax will be fundamentally in=
consistent with the rest of the language.<br><br><u><b>You:</b></u> ...sure=
, but we can fix that by making <i>more parts</i> of the language inconsist=
ent too!<br><br><u><b>Us:</b></u> :facepalm:<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div></div><div>Anyway,=
=C2=A0keeping with my onus, I take from here: <a href=3D"https://github.com=
/solodon4/Mach7" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fsolodon=
4%2FMach7\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEnB8TGg0vomxHAuGPu7g4hCvv=
XDg&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.google.com/u=
rl?q\x3dhttps%3A%2F%2Fgithub.com%2Fsolodon4%2FMach7\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNEnB8TGg0vomxHAuGPu7g4hCvvXDg&#39;;return true;">https://gi=
thub.com/solodon4/<wbr>Mach7</a></div><div>this example:</div><div><br></di=
v><div>void print(const boost::variant&lt;double,float,<wbr>int&gt;&amp; v)=
<br>{<br>=C2=A0=C2=A0=C2=A0 var&lt;double&gt; d; var&lt;float&gt; f; var&lt=
;int&gt; n;</div><div>=C2=A0=C2=A0=C2=A0 match(v)<br>=C2=A0=C2=A0=C2=A0 {<b=
r>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case(C&lt;double&gt;(d))</div><div>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cout &lt;&lt; &quot;double=
 &quot; &lt;&lt; d &lt;&lt; endl; break;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
case(C&lt;float&gt; (f))</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 cout &lt;&lt; &quot;float=C2=A0 &quot; &lt;&lt; f &lt=
;&lt; endl; break;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case(C&lt;int&gt;=C2=
=A0=C2=A0 (n))</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 cout &lt;&lt; &quot;int=C2=A0=C2=A0=C2=A0 &quot; &lt;&lt; n &l=
t;&lt; endl; break;<br>=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=A0 endmatch<=
br>}</div><div><br></div><div>This=C2=A0doesn&#39;t use braces in the case =
statements and I don&#39;t find it=C2=A0shocking.</div></div></div></blockq=
uote><div><br>C++ doesn&#39;t require the use of braces <i>in case statemen=
ts</i>. Ignoring that the `case`s are not constant expressions and the use =
of the non-standard `match/endmatch` syntax (note that `endmatch` is there =
because it feeds into the macro magic, not because the developer actually w=
anted it), this is perfectly legitimate C++ code now.<br><br>C++ requires t=
he use of braces with `switch` (if you want to have more than one statement=
). We are talking about how your syntax lacks <i>any braces</i>.<br><br>So =
I fail to see how this addresses anything people have said about your propo=
sal.<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d0632288-462d-4995-8b35-bbcbad67b5d7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d0632288-462d-4995-8b35-bbcbad67b5d7=
%40isocpp.org</a>.<br />

------=_Part_1423_359199165.1483764264846--

------=_Part_1422_602931699.1483764264846--

.