After thinking about this more last evening and reading code in the new
style, I've changed my mind.
I think my previous feedback was too influenced by the fact that I disliked
a new predeclared identifier being introduced, and that the style was
different from what I'm used to in TypeScript/Java.
I'm now liking the uniformity and the explicitness.
> In general, a language that's easier to parse mechanically is also easier
to parse by a human.
Good point, and I now agree that it's the case here. I also like that
requiring any/interface{} explicitly removes the confusion in code such as:
func Print[T, S Stringer]()
because "T, S Stringer" in non-type parameters means that T, S are both
type Stringer, but is confusing in type parameters (namely, is T any or
Stringer?).
> So, assuming the first one isn't an option, do you still find the last
one preferable over the second one?
I prefer the second one, [T any]/[T Foo].
On Wed, Sep 2, 2020 at 11:19 PM Axel Wagner <axel.wagner...@googlemail.com>
wrote:
> On Wed, Sep 2, 2020 at 7:02 PM Nishanth Shanmugham <
> nishanth.gerr...@gmail.com> wrote:
>
>> If it is intended at simplification for parsers, […] If it is intended to
>> improve readability for readers of generic code
>>
>
> I would argue that this is not a dichotomy. On the contrary: In general, a
> language that's easier to parse mechanically is also easier to parse by a
> human. The converse isn't always true, but still, optimizing for mechanical
> parsers also tends to help humans.
>
>
>> 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.
>>
>
> The choice isn't really between writing
> [T]/[T Foo],
> or writing
> [T any]/[T Foo].
> It's between the latter and
> [type T]/[type T Foo].
>
> So, assuming the first one isn't an option, do you still find the last one
> preferable over the second one?
>
>
>> 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
>> <https://groups.google.com/d/msgid/golang-nuts/269b0470-d197-4a7d-af37-bec63e27ef10n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
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/CABX8%3DwfhCJOtvmsOi3ePhEa5z0CwBZE63J81eMYXZmd5fSeN5g%40mail.gmail.com.
