3 ms·

It actually causes ambiguous syntax that isn't easy to solve. See: https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#

by kyrra 6y ago

It actually causes ambiguous syntax that isn't easy to solve. See: https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use-the-syntax-like-c_and-java https://go.googlesource.com/proposal/+/refs/heads/master/des... a, b = w < x, y > (z) Is this code doing 2 boolean compares, or is it calling a function with "w" with types x and y?

hnlmorg 6y ago
I know it’s not a popular opinion, but one thing I love about Perl and wished more languages adopted was the way how variables and functions could be prefixed by a special character (‘$’ for scalars, ‘%’ for hashes, ‘@‘ for arrays and ‘&’ for functions, though the latter was optional). Perl had a lot of properties that made it look a lot like executable line noise but those prefixes did help with readability in a way that a lot of more readable languages lack. In the case of Go and the example you’ve given, if ‘W’ were a function then the code should read like this: a, b = w() < x, y > (z)
- Jtsummers 6y ago
  In the example, we can't tell if w is a generic function or not (by looking at this line of code). Remove the spaces, as would be more conventional: w<x,y>(z) Is this two expressions on one line or one expression with two type parameters? Possible groupings: (w<x,y>)(z) // w is a generic function (w<x),(y>(z)) // two comparisons
- blandflakes 6y ago
  The parens look like "helping ambiguous syntax" rather than "should read like this" here - if z is an argument to w, there was already a set of parens signifying the function call.
robocat 6y ago
Could they not make the space (or no space) part of the syntax after the <. gofmt means that white space could be made significant... which is the lesser evil: syntactic whitespace or inconsistent semantic meaning (compared to most other languages)? I detest how syntactically overloaded our few ASCII symbols are, and using square brackets for templates seems wrong. Edit: Even better, use gofmt to convert each ASCII symbol into several unique Unicode symbols depending on usage, to show the semantic meaning. So [] as array is represented differently from [] as the template operator. Edit 2: I suspect this one decision will prevent some developers from investigating golang and thus affecting uptake - choice of syntax matters.
- hnlmorg 6y ago
  The << / >> characters (sorry on phone so can’t post the actual Unicode characters) was proposed and, like yourself, the Go team decided it might put people off. But to be honest I actually would have been ok with it.

by kyrra 6y ago

hnlmorg 6y ago

I know it’s not a popular opinion, but one thing I love about Perl and wished more languages adopted was the way how variables and functions could be prefixed by a special character (‘$’ for scalars, ‘%’ for hashes, ‘@‘ for arrays and ‘&’ for functions, though the latter was optional). Perl had a lot of properties that made it look a lot like executable line noise but those prefixes did help with readability in a way that a lot of more readable languages lack. In the case of Go and the example you’ve given, if ‘W’ were a function then the code should read like this: a, b = w() < x, y > (z)

Jtsummers 6y ago
In the example, we can't tell if w is a generic function or not (by looking at this line of code). Remove the spaces, as would be more conventional: w<x,y>(z) Is this two expressions on one line or one expression with two type parameters? Possible groupings: (w<x,y>)(z) // w is a generic function (w<x),(y>(z)) // two comparisons
blandflakes 6y ago
The parens look like "helping ambiguous syntax" rather than "should read like this" here - if z is an argument to w, there was already a set of parens signifying the function call.

robocat 6y ago

Could they not make the space (or no space) part of the syntax after the <. gofmt means that white space could be made significant... which is the lesser evil: syntactic whitespace or inconsistent semantic meaning (compared to most other languages)? I detest how syntactically overloaded our few ASCII symbols are, and using square brackets for templates seems wrong. Edit: Even better, use gofmt to convert each ASCII symbol into several unique Unicode symbols depending on usage, to show the semantic meaning. So [] as array is represented differently from [] as the template operator. Edit 2: I suspect this one decision will prevent some developers from investigating golang and thus affecting uptake - choice of syntax matters.

hnlmorg 6y ago
The << / >> characters (sorry on phone so can’t post the actual Unicode characters) was proposed and, like yourself, the Go team decided it might put people off. But to be honest I actually would have been ok with it.