On Tuesday, October 6, 2020 at 1:54:16 PM UTC-4 Ian Lance Taylor wrote:
> On Tue, Oct 6, 2020 at 10:28 AM tapi...@gmail.com <tapi...@gmail.com>
> wrote:
> >
> > IMO, the bar function is cleaner and more readable than the foo
> function.
> > How do you think?
> >
> > func foo() {
> > if vs := f(); len(vs) == 0 {
> > } else {
> > for _, v := range vs {
> > }
> > }
> >
> > if vs := f(); len(vs) == 0 {
> > } else {
> > switch {
> > case len(bs) == 0:
> > case len(bs) == 1:
> > default:
> > }
> > }
> > }
> >
> > // vs.
> >
> > func bar() {
> > if vs := f(); len(vs) == 0 {
> > } else for _, v := range vs {
> > }
> >
> > if vs := f(); len(vs) == 0 {
> > } else switch {
> > case len(vs) == 0:
> > case len(vs) == 1:
> > default:
> > }
> > }
>
> Well, why stop there? Why not
>
> if vs := f(); len(vs) == 0 {
> } else f2()
>
> if vs := f(); len(vs) == 0 {
> } else x = y
>
These are different. "for" and "switch" are both code block start keywords,
just the same as "if".
>
> There is a simple rule:
> if <condition> <block> [else <block>]
> In fact, for a while in the very early days of Go, that was the only
> rule. But experience showed that people naturally want to write
> if/else if/else, and having to add extra braces was frustrating, and
> they tended to stack up. So the rule was extended to (roughly):
> if <condition> <block> [else if <condition> <block> [else <block>]]
>
> There's no obvious need to extend the rule in any other way. It's not
> something that people are running into.
>
> Ian
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/7ab1cfb9-8fc8-43c7-88f9-6a06cca7a0d7n%40googlegroups.com.
