On Sat, Jul 18, 2020 at 11:12 AM roger peppe <rogpe...@gmail.com> wrote:
Thanks for taking time to think about it.
> A few reasons that I'm not keen on your $, @ proposal:
>
> - elsewhere in Go, when a name is defined, there is one clear construct that
> defines it, not an arbitrary place within a type expression. That's not the
> case in your proposal.
I don't think variables are declared in just one construct. Some ways
that come to my mind immediately:
var a = 42
a := 42
func f(a int) {...}
All are clear and that's good. All are allowed just in their
respective contexts as exemplified above. For example, the short
variable definition is not allowed within the list of function
parameters.
The term "type expression" does not appear in [1], so let me now
assume you meant "type literal" and/or just "type" as that includes
defined types.
The alternative proposal makes names starting with $ to mean a type
parameter right at the tokenizer. In the same way as variable
declaration is accepted by the grammar only in certain contexts, type
parameters are accepted in the alternative proposal only in the
context of a type literal, where a type name is allowed. Nowhere else.
var a T
var a $T
var a map[T]U
var a map[$T]U
var a map[$T]$U
var a map[T]$U
In the original proposal a new place where type can appear is the
instantiation of a generic type. Same for the alternative draft:
foo(int)(42) // original, predeclared type
foo@int(42) // alternative
func foo(type T)(x T) { // original
bar(T)(x) // instantiate bar with type parameter T
}
func foo(x $T) { // alternative
bar@T(x) // instantiate bar with type parameter T, the $ sign
is optional as T was already declared above
}
So I'm not sure where "arbitrary place" comes from. Note that the
alternative draft specifies the type parameter declaration must occur
at its first lexical occurrence.
func f(x $T) T { ... } // Is valid in the alternative draft
func f(x T) $T { ... } // Is not valid in the alternative draft
> - the ordering of the type parameters is important, but is implicit in the
> ordering of the type expressions rather than explicit. The order of the type
> parameters may not even be visible to an external consumer of an API (for
> example, consider a function that returns a generic struct where the only
> generic elements are private fields). Reordering fields within a struct could
> affect the type parameter order - something that should be possible to do
> backwardly compatibly.
This is true and to an extent was mentioned in the alternative draft.
There's a possible hack for fixing the order in a function and/or a
struct by listing the prefered order using blank (underscore) variable
declarations or zero sized fields, but that's ugly. Wait, is it
really? Firstly, the need for that will probably not be common,
secondly `var _ myInterface = (*myType)(nil)` etc. is a common idiom
and it's rather similar to var _ $T; var _ $U, isn't it?
I guess that type parameters will in practice appear most often right
in the signature anyway.
> - it's strictly less general than the original proposal. There's no way to
> write a generic function that doesn't mention the generic type as part of its
> signature. For example, you couldn't write this function:
>
> func zeroPtrInterface[type T]() interface{} {
> return new(T)
> }
Example from the alternative draft, page 2:
func NewFoo(limit int) Foo {
r := new($T Fooer)
r.SetLimit(limit)
return r
}
So the "couldn't write this" example is:
func zeroPtrInterface() interface{} {
return new($T)
}
> - I'm not keen on the @, $ syntax. It co-opts not just one but two new
> symbols into the Go syntax, and I suspect that the merging of reference and
> definition will make the resulting code hard to read.
It's subjective, so saying I like it does not matter. Not sure what is
meant by "the merging of reference and definition", can you please
clarify?
----
[1]: "Type Parameters - Draft Design",
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md
by Ian Lance Taylor and Robert Griesemer, June 16, 2020.
--
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-WEryOJqvgD76ejDtRmsa8vrXmTZSVpTDt_FEwdeBZAdA%40mail.gmail.com.
