Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: Go2: provide while as alias for for #29871

Closed
ghost opened this issue Jan 22, 2019 · 4 comments

Comments

@ghost
Copy link

commented Jan 22, 2019

I think, this proposal will get many of 馃憥 , and it could be issued as normal proposal, but i would like to put it here.

I have learned and written in many languages the last decades; everywhere are discussions (especially for newbies), when to use for and when to use while.

With evolution of languages, for stays generally for a counting iteration and while for looping.

When i read my first lines about Go i started wondering, why Go is making so much different, but uses only for - instead of while.

Lexically, for is nearly always a mistake. Neither counting, nor looping nor ranging - lexically more correct is in all cases: while (in other words: as long as)

Whereas the one and only case for for is counting and it's ok for ranging, a while is lexically correct in all cases:

while {...}
while a < b {...}
while a := 0; a < 10; a++ {...}
while a, b := range c {...}

So, i do not proposal the breaking change of directly renaming for to while, instead i would like to proposal to extend one of the very useful aliases in the language; the first and maybe only one of this kind.

Go is an amazing language and with while it can become more beautiful.

But i cannot define the costs to do this.

Thanks

@gopherbot gopherbot added this to the Proposal milestone Jan 22, 2019

@gopherbot gopherbot added the Proposal label Jan 22, 2019

@mvdan

This comment has been minimized.

Copy link
Member

commented Jan 22, 2019

The obvious cost would be that all the programs that use while as names would suddenly break. The langauge would also get a tiny bit more complex. And we'd start style wars over when for or while should be preferred and why.

We already have this issue with the multiple ways to declare variables, for example. Some prefer var s []string, others s := []string{}. I don't think we should add more ways to do the same thing unless there's a clear strong need for it.

@ghost

This comment has been minimized.

Copy link
Author

commented Jan 22, 2019

First of all, i want to say, i am very new to Go, but i like the language very much 鉂わ笍

I like it too, that Go is slowly evolving changes and new features 馃憤

As this is a big deal with the language, i proposed only an alias for for - only because i am troubling with this for longer time and we are talking here about Go2, a possibly new decade of Go (whereas while is only some lexical fine-tuning)

About:

We already have this issue with the multiple ways to declare variables, for example.
Some prefer var s []string, others s := []string{}.

I do not feel that's a discus in the same direction; both exists and := is only provided in function scope.

The obvious cost would be that all the programs that use while as names would suddenly break.

Refactoring should be absolutely no problem. I have never used while as a name, neither as name, prefix or suffix, so it should be very rarely to talk about.

But i just want to start talking about and getting response; should be said, that all those who are new to Go eventually don't look at Go2 proposals.

But, thank you 馃憤

@bcmills

This comment has been minimized.

Copy link
Member

commented Jan 22, 2019

Lexically, for is nearly always a mistake.

If it helps, you can read it as, 鈥for as long as [鈥鈥.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jan 22, 2019

Thanks for the suggestion, but this is not a change that we are going to make at this stage in the language's development. There are many things that every new Go programmer has to learn; this is one of the minor ones. Changing this today would break many existing programs, would lead to endless style discussions as @mvdan mentioned, and would benefit very very few people. The cost is too high for the benefit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can鈥檛 perform that action at this time.