Resending to the list after mistakenly replied off list. My apologies.
----
On Wed, Jul 15, 2020 at 10:59 PM Ian Lance Taylor <i...@golang.org> wrote:
> Thanks for the detailed writeup.
It might have been too detailed and suffered from low information
density. Let me amend it with a tl;dr:
----
1. The main idea is to remove the parenthesized type list while
keeping exactly 100% of the semantics of the original draft.
2. $T declares a type parameter. (For the mnemotechnical clue cf. the
POSIX shell env vars or Tcl vars, to name a few.)
3. U@V, u-at-v, instantiates generic type U using type argument V.
(cf. value instance at address, now type-parameter instantiated at
type)
4. Instantiating a generic type W with a type parameter X that is
declared in the same place means plugging 2 into 3, hence W@$X.
----
The particular syntax is less important here. But it seems to remove
the parsing ambiguities of the original draft.
Motivational example of a function signature:
Original:
func Keys(type K comparable, V interface{})(m map[K]V) []K
Alternative:
func Keys(m map[$K comparable]$V) []K
----
> I'm a bit concerned about name
> scoping.
Then I must have miscommunicated something. The intent is to have the
type parameters live in the exact same scope as in the original draft.
The comments about $T and T in the same scope just tried to say that
there cannot be both a type parameter $T and other named, but
different thing T in the same scope. Exactly as in the original, but
there the $ sign does not exist, so there's nothing to talk about in
this regard.
> Also about the fact that constraints can apparently show up
> anywhere; is that always going to work?
In the original draft a type parameter constraint appears only once,
next to the type parameter declaration. In the alternative one is the
same, only once, next to the type parameter declaration. Hence I
expect the alternative version to work in exactly the same way.
> And I don't think that
> Vector@$T is going to be all that intuitive for anybody to read.
This is subjective by definition, but I'd like to point out something
different. We write and read code not by intuition but by using quite
precise knowledge about the grammar and semantics of the language.
Intuition can of course help us to learn that necessary level of
knowledge to become a fluent language user.
f(x), for example, is intuitively a function call, because we write
f(x) in math classes in school.
a+b is intuitively an addition, because that's how we write it in math.
a*b is not very intuitive, because we write multiplication in math as
ab, a.b, axb. (The last has at least some visual resemblance to the
asterisk, admitted.)
Okay, now that we know the correct multiplication symbol, what an
unary multiplication is intuitively supposed to mean and why it
actually denotes dereferencing a pointer or pointer-ness of a type?
a^b is intuitively exponentiation, because that's how we write it in
math. But it's actually a xor b in Go.
The conclusion is, sometimes intuition helps in learning the language,
other times it can hurt. The only thing that matters at the end of the
day is knowing the language and that's no more connected much with
intuition.
--
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/CAA40n-WEv4uoa0eSyE5M2yimn6tPJ7_vHFxPW5W2mCk1zTZfmg%40mail.gmail.com.
