Some feedback on requiring any/interface{} explicitly.
> We feel that the cost of the new predeclared identifier “any” is
outweighed by the simplification achieved by making all parameter
lists syntactically the same
Why is this simplification preferred? If it is intended at simplification
for parsers, I think that on its own it does not warrant the addition of a
new predeclared identifier to the language spec. (We should rather do the
extra work in the parsers.)
If it is intended to improve readability for readers of generic code, I
think that the opposite is happening. Writing `any/interface{}` for a
non-constrained type adds more clutter than it contributes to reading
uniformity. It is common in languages such as TypeScript and Java for a
non-constrained type to be simply written as "T", which in my experience,
has been readable and clutter-free.
On Monday, August 31, 2020 at 11:04:17 PM UTC+5:30 Ian Lance Taylor wrote:
> On Mon, Aug 31, 2020 at 10:25 AM samir.el...@gmail.com
> <samir.el...@gmail.com> wrote:
> >
> > Great improvements. Well done.
> >
> > Any intentions to make methods accept additional type arguments ?
>
> See
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#No-parameterized-methods
> .
>
> Ian
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/269b0470-d197-4a7d-af37-bec63e27ef10n%40googlegroups.com.
