[X] Has this idea, or one like it, been proposed before?
[ ] Does this affect error handling?
[ ] Is this about generics?
[X] Is this change backward compatible? Breaking the Go 1 compatibility guarantee is a large cost and requires a large benefit
Has this idea, or one like it, been proposed before?
It is about well-known "enforcement of style" by language. I suggest parity.
Does this affect error handling?
No
Is this about generics?
No
Proposal
I've found how do you track auto-insert of semicolon. And it seems that you can check whether it is needed or already in place, so the style would not be enforced. I'd like to see that in scanner.go in Scan() you check 2 nearby tokens, and if it matches newline after ) and next is {, then you don't automatically insert semicolon. And if it is newline after ) and next is not {, then you insert. This way new-line closure can exist alongside auto-insert. I don't think it is too hard to implement.
Language Spec Changes
No response
Informal Change
No response
Is this change backward compatible?
Yes.
Both should be compatible if implemented close to my request:
func f() {
//code
}
func f()
{
//code
}
Orthogonality: How does this change interact or overlap with existing features?
No response
Would this change make Go easier or harder to learn, and why?
It would let people who like new-line-closure style use Golang comfortably, i.e. make it more accessible, inclusive.
seankhliao
commented
2 weeks ago
Go Programming Experience
Intermediate
Other Languages Experience
C family, Rust
Related Idea
Has this idea, or one like it, been proposed before?
It is about well-known "enforcement of style" by language. I suggest parity.
Does this affect error handling?
No
Is this about generics?
No
Proposal
I've found how do you track auto-insert of semicolon. And it seems that you can check whether it is needed or already in place, so the style would not be enforced. I'd like to see that in scanner.go in Scan() you check 2 nearby tokens, and if it matches newline after ) and next is {, then you don't automatically insert semicolon. And if it is newline after ) and next is not {, then you insert. This way new-line closure can exist alongside auto-insert. I don't think it is too hard to implement.
Language Spec Changes
No response
Informal Change
No response
Is this change backward compatible?
Yes. Both should be compatible if implemented close to my request:
func f() { //code }
func f() { //code }
Orthogonality: How does this change interact or overlap with existing features?
No response
Would this change make Go easier or harder to learn, and why?
It would let people who like new-line-closure style use Golang comfortably, i.e. make it more accessible, inclusive.
Cost Description
Additional branch.
Changes to Go ToolChain
No response
Performance Costs
Couple of CPU cycles per pattern match.
Prototype
Mentioned in proposal.