switch v2

[gmis...@gmail.com]

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

[D. B.]

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.

[Magnus Fromreide]

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

[gmis...@gmail.com]

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?

[gmis...@gmail.com]

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?

[D. B.]

On Fri, Jan 6, 2017 at 11:10 AM, <gmis...@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.
 

[D. B.]

...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 ;-)

[gmis...@gmail.com]

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?

 

[gmis...@gmail.com]

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 -) 

[gmis...@gmail.com]

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 :)

[Magnus Fromreide]

On Fri, Jan 06, 2017 at 03:12:27AM -0800, gmis...@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:>

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

[D. B.]

On Fri, Jan 6, 2017 at 11:41 AM, <gmis...@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)
 

[Viacheslav Usov]

On Fri, Jan 6, 2017 at 12:32 AM, <gmis...@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.

[gmis...@gmail.com]

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.

[gmis...@gmail.com]

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.

[D. B.]

On Fri, Jan 6, 2017 at 12:53 PM, <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.

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.

[Nicol Bolas]

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

[gmis...@gmail.com]

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.

[gmis...@gmail.com]

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.

[Nicol Bolas]

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.

[gmis...@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?

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. :)

[Viacheslav Usov]

On Fri, Jan 6, 2017 at 1:53 PM, <gmis...@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.

[Nicol Bolas]

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.

[D. B.]

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.

[Domen Vrankar]

2017-01-06 17:09 GMT+01:00 <gmis...@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

[gmis...@gmail.com]

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.

 

[gmis...@gmail.com]

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

[Nicol Bolas]

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.