-
Notifications
You must be signed in to change notification settings - Fork 17.8k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
proposal: make generic parentheses declaration order consistent with array bracket declaration order #36533
Comments
I don't understand why this is better. Since we are using parentheses, and since type parameters are much more like non-type parameters than they are like anything else, consistency with function declarations and calls seems more useful than consistency with array declarations and uses. |
For me it makes it more readable to distinguish generic syntax. Especially this two lines messes with my head and predict I will be making regular typo's for example forgetting the word
Also I believe alignment is important
|
Hmm, I am not sure if I like this or not, however would then this syntax also be allowed?
If so that could make writing generics easier, although it might make reading them harder again. |
Your suggestion looks nice to have some sort of decoration ability like
And if you extend it with something like
|
Upon discussion with Go 2 proposal review committee, we would like to fold this issue into the general generics issue #15292. Please also feel free to add a link to this issue to https://golang.org/wiki/Go2GenericsFeedback. We don't think it will be helpful to keep multiple generics syntax issues open simultaneously, spreading the discussion to too many different places. -- for @golang/proposal-review |
https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md
Can we maybe just reorder the generic parentheses like array brackets order please?
So everything is exactly the same as the current contract proposal just reordered a bit.
Basically following the same order as array's get declared
[5]int
Related to: #36177 but yet another suggestion in case it wasn't suggested before
EDIT: Iteration of this proposal (see comments) to something like this to separate generics completely from regular go code
General generics issue: #15292 (see comment below)
The text was updated successfully, but these errors were encountered: