On Sat, 18 Jul 2020 at 11:05, Jan Mercl <0xj...@gmail.com> wrote:
> 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.
I didn't say there was exactly one construct for each *kind* of name
definition. In current Go, when a name is defined, it's defined inside a
construct that is explicitly about defining that name. By contrast, in your
proposal, we take an arbitrary type and add a dollar qualifier on a name
somewhere inside it, and that turns the construct into a definition. That
doesn't feel very Go-like to me.
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.
>
Yes, just "type" is sufficient, although that term has two purposes - it
can refer both to the program text that declares the type and to the actual
type itself once defined. I was using "type expression" in an attempt to
say the former.
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.
>
It's an arbitrary place because it's somewhere buried inside the generic
type
or function. ISTM that it's not great that the form of the types or code
should
directly determine the order of the type parameters. To take an example,
say I have some code that uses some generic container defined externally:
type S struct {
container *external.Container@T1@T2
}
To make an instance of S, we need to mention the types in the same order
that we gave them to the external.Container type:
S@string@int
Now what if we want to change the private field to use some alternative
container implementation that happens to take
its type arguments in a different order?
type S struct {
container *other.Container@T2@T1
}
This is an API-breaking change, but it's both non-obvious and not entirely
trivial to work around (we'll need to define our own wrapper type for
other.Container that has the same type parameter order).
> 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.
>
I'm not keen on this rationalisation. It feels like working around
something that could have been done correctly from the outset.
>
> > - 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
> }
>
The above example exemplifies the problem with this approach. NewFoo is a
generic function that has no appearance of being generic in the signature,
and its public API is determined crucially by the positioning of the
statements within the code, something that should be considered private.
Here's another example:
type S struct {}
func (s S) Bz() $B {
var b B
return b
}
func (s S) Az() $A {
var a A
return a
}
AFAICS in this case the ordering of the methods of S influences the order
of the type parameters required to instantiate S.
If we reorder the Az and Bz methods, then we're breaking compatibility.
What if they're in different files?!
> 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?
>
I mean that we have one place that's both defining new names and acting as
a type declaration. It feels to me like you're really trying to avoid
defining the generic types as parameters, but you end up with them as
implicitly declared parameters anyway, with some additional problems picked
up along the way.
cheers,
rog.
> ----
>
> [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/CAJhgacgPf5Jn-yGNKQYrSZR%3Duhb2ZYFVErC7tS900DiHqSuBKQ%40mail.gmail.com.
