Hi,
The type parameters in the current proposal uses `(type xxx)` which is visually
hard to distinguish from function parameters.
There are reasons stated in the proposal to not adopt <> (which is common in
other languages) which I'm not going to challenge. But have you considered
`()`? It sho
It's covered in the generics design doc, and by about a dozen threads on
golang-nuts at this point. Unless the parsing issues can be addressed
satisfactorily, that option is off the table right now. Same for [T] and
other variations.
- Dave
On Sat, Jun 20, 2020 at 10:34 AM wrote:
> Hi,
>
> The
On Sun, Jun 21, 2020 at 3:45 AM David Anderson wrote:
> It's covered in the generics design doc, and by about a dozen threads on
> golang-nuts at this point.
I think that the suggestion was for F(), not F. If so, that
suggestion isn't covered by the generics design doc or the other
golang-nuts t
On Sat, Jun 20, 2020 at 10:33 AM wrote:
>
> The type parameters in the current proposal uses `(type xxx)` which is
> visually hard to distinguish from function parameters.
>
> There are reasons stated in the proposal to not adopt <> (which is common in
> other languages) which I'm not going to c