spec: generics: permit type parameters on aliases #46477

mdempsky · 2021-06-01T00:35:01Z

The generics proposal says "A type alias may refer to a generic type, but the type alias may not have its own parameters. This restriction exists because it is unclear how to handle a type alias with type parameters that have constraints."

I propose this should be relaxed and type aliases allowed to have their own type parameters. I think there's a clear way to handle type aliases with constrained type parameters: uses of the type alias need to satisfy the constraints, and within the underlying type expression those parameters can be used to instantiate other generic types that they satisfy.

I think it's fine to continue allowing type VectorAlias = Vector as in the proposal, but this should be considered short-hand for type VectorAlias[T any] = Vector[T]. More generally, for generic type B with type parameters [T1 C1, T2 C2, ..., Tn Cn], then type A = B would be the same as type A[T1 C1, T2 C2, ..., Tn Cn] = B[T1, T2, ..., Tn].

In particular, something like this would be an error:

type A[T comparable] int
type B[U any] = A[U]   // ERROR: U does not satisfy comparable
type C B[int]

As justification for this, analogous code in the value domain would give an error:

func F(x int) {}
func G(y interface{}) { F(y) }  // ERROR: cannot use y (type interface{}) as int
func H() { G(42) }

I suspect if TParams is moved from Named to TypeName and type instantiation is similarly changed to start from the TypeName instead of the Type, then this should work okay.

/cc @griesemer @ianlancetaylor @findleyr @bcmills

The text was updated successfully, but these errors were encountered:

findleyr · 2021-06-01T18:40:37Z

If this proposal were accepted, would the following code be valid?

type A[T any] int
type B[U comparable] = A[U]

I.e. would it be possible to define an alias which tightens the constraints of the aliased type?

IMO the example in the value domain is more analogous to defining a new named type, which already behaves as expected:

type A[T comparable] int
type B[U any] A[U] // ERROR: U does not satisfy comparable

Aliasing seems more analogous to function value assignment, for which we don't redeclare parameters:

func F(x int) {}
var G = F

I think you're right about how this could be implemented, but I wonder if it is conceptually coherent. Specifically, I wonder about whether we should think of the declaration as parameterizing the type, or as defining a parameterized type, and whether it still makes sense to call the example with additional restrictions above an alias.

I'll also note that as you point out, our decisions with respect to the go/types API have real consequences for how easy it would be to relax this restriction on aliases in the future, so it is good to talk about this now. Thanks for raising this issue!

mdempsky · 2021-06-01T19:11:29Z

I.e. would it be possible to define an alias which tightens the constraints of the aliased type?

Yes. U (type parameter with bound comparable) satisfies the constraint any, so that's a valid type declaration in my mind. But similarly, trying to instantiate B[[]int] would be invalid, because []int does not satisfy comparable, even though it satisfies the underlying any.

I would expect that the type checker would see B[[]int], resolve B to the TypeName and check it against the type parameters, and then reject it as invalid, before proceeding to instantiating/substituting its Type with the type argument []int.

Aliasing seems more analogous to function value assignment, for which we don't redeclare parameters:

Note that var G = F is really shorthand there for var G func(int) = F. You're not allowed to write var G func(interface{}) = F, for example, even if you only ever call G with int arguments.

But this is also why I suggest still allowing type A = B as shorthand for explicitly writing out type parameters for the alias declaration.

griesemer · 2021-06-01T19:17:21Z

There is a reason why we didn't do this in the first place.

I don't have any principal objections to this proposal. If we accept this, I wonder whether we should still permit the type A = B form as it does deviate from the current design which requires that every use of a generic type requires an instantiation.

~~I'm inclined to proceed in one of two ways:~~
~~1) Disallow (not implement) the form type A = B for Go1.17. It's not crucial and we can always add it later.~~
~~2) Implement this proposal instead of permitting type A = B.~~

bcmills · 2021-06-01T19:21:25Z

I seem to recall @rogpeppe raising a similar point in various conversations.

bcmills · 2021-06-01T19:27:55Z

@findleyr

Aliasing seems more analogous to function value assignment, for which we don't redeclare parameters:

Note that we do allow function value assignment to strengthen (but not weaken) a type via assignability, which IMO is analogous to strengthening type constraints on a type declaration.

Consider this program:

package main

import "context"

func cancel() {}

type thunk func()

var f = cancel
var g context.CancelFunc = cancel

In that program, var f = cancel is shorthand for var f func() = cancel.

The declaration var g context.CancelFunc = cancel refers to the exact same function value, but with a stronger type (one that is not assignable to thunk).

jimmyfrasche · 2021-06-01T19:35:46Z

It looks like it could fall out of the definition but, to be explicit, partial application would also be useful:

type Named[T any] = Map[string, T]

mdempsky · 2021-06-01T19:36:53Z

@griesemer If we proceed with this proposal, I think it could be a nice convenience to keep type A = B as short-hand. But as it's not essential, I'd similarly be fine with just removing it altogether. We can always re-add it in the future if appropriate.

And yes, the deviating from the norm of requiring instantiation is what threw me off. I had written some code that was working under the assumption that if I only started from non-generic declarations, then I would never see a non-instantiated type. But that doesn't hold for the type A = B form. (Fortunately though, it's not hard to special case this one instance either.)

findleyr · 2021-06-01T19:44:27Z

@bcmills

Note that we do allow function value assignment to strengthen (but not weaken) a type via assignability, which IMO is analogous to strengthening type constraints on a type declaration.

The example from #46477 (comment) made the analogy of function parameters with type parameters (which makes sense). In that analogy, we don't allow changing function parameter types when assigning [example], i.e. we don't support covariant function assignment.

bcmills · 2021-06-01T21:18:43Z

In that analogy … we don't support covariant function assignment.

Sure, but pretty much the entire point of type parameters is to support variance in types. 😉

neild · 2021-06-02T03:21:17Z

What is the use case for permitting parameters on type aliases?

griesemer · 2021-06-02T03:46:15Z

~~@neild The same reason for which type aliases were introduced in the first place, which is to make refactoring across package boundaries easier (or possible, depending on use case).~~

I misread this comment. See below.

griesemer · 2021-06-02T04:03:44Z

Going through my notes I remember now why we didn't go this route in the first place: Note that an alias is just an alternative name for a type, it's not a new type. Introducing a smaller set of type arguments (as suggested above), or providing stronger type constraints seems counter that idea. Such changes arguably define a new type and then one should do that: declare a new defined type, i.e., leave the = away. I note that @findleyr pointed out just that in the 2nd comment on this proposal.
This would mean that the respective methods also have to be redefined (likely as forwarders) but that seems sensible if the type constraints are narrowed or partially instantiated.

In summary, I am not convinced anymore that this is such a good idea. We have explored the generics design space for the greater part of two years and the devil really is in the details. At this point we should not introduce new mechanisms until we have collected some concrete experience.

I suggest we put this on hold for the time being.

neild · 2021-06-02T04:19:12Z

@griesemer I don't see what the refactoring case is for changing the constraints of a type. As you say, an alias is just an alternative name for a type, but an alternative name with altered constraints is a subtler concept that I struggle to see the use for.

I may be missing something. A concrete example of when you'd use this would be useful.

griesemer · 2021-06-02T04:40:46Z

@neild Agreed - I misread your comment as "what is the use of allowing alias types for generic types" - my bad. See my comment just before your reply.

mdempsky · 2021-06-02T09:33:00Z

I don't see what the refactoring case is for changing the constraints of a type.

Under this proposal, you can do more with parameterized type aliases than just change the constraints. E.g., see #46477 (comment) for using type parameters to provide default arguments to other generic types. I called out the constraint change to clarify the semantics, not because I expect that's something people are likely to do in practice.

I anticipate analogous to how we added type aliases to facilitate large-scale refactorings while maintaining type identity, we're going to face situations where generic types need to be refactored to add, remove, or change parameters while also maintaining type identity. Having parameterized type aliases would facilitate that. I think if just "declaring a new defined type" was always an adequate solution, we could have skipped adding type aliases too.

I think it's fine though if Go 1.18 doesn't have parameterized type aliases. But I at least think we should try to ensure the go/types APIs are forward compatible with adding parameterized type aliases.

findleyr · 2021-06-02T13:49:11Z

@bcmills

Sure, but pretty much the entire point of type parameters is to support variance in types. 😉

FWIW, I don't follow this argument. We still support variance in types no matter what we decide about this proposal, just like we allow variance in function arguments whether or not we allow covariant assignment of function values. I think we're dipping in and out of the 'meta' realm. The point I was trying to make is that if we're trying to argue by analogy with the value domain, wrapping a function is more like defining a new named type (or perhaps more correctly like struct embedding), and aliasing is more like assignment. Since we don't allow covariant assignment for functions, it's arguably a bit inconsistent to allow covariant assignment for "meta functions" (if that's how we think about generic declarations).

@griesemer

This would mean that the respective methods also have to be redefined (likely as forwarders) but that seems sensible if the type constraints are narrowed or partially instantiated.

Or use embedding, which might be more analogous to wrapping a function in the value domain.

I suggest we put this on hold for the time being.

Independent of whether we relax the restriction on aliases, this proposal indirectly makes the point that it matters whether we think of the "type" as generic or the "declaration" as generic, both in the current APIs and for future extensions of the language. For example, thinking of the type declaration as generic allows relaxing this restriction on aliases. Thinking of the function type as generic allows for generic interface methods and generic function literals. If we put this proposal on hold, we will still need to make API decisions that affect its feasibility.

mdempsky · 2021-06-02T20:30:58Z

[re: value vs type domain analogies]

I want to clarify that I made this analogy initially to help explain how I intuit the relationships here. Go's values and types operate sufficiently distinctly and irregularly that I think trying to read too far into the analogy is going to hit rough edges and become more philosophical than actionable. E.g., the value domain has no analog to defined types and type identity, because it's impossible to create a copy of a Go value that's distinguishable from the original. (Emphasis: I'm talking specifically about values here, not variables.)

Certainly we should revisit these discussions when it comes time to add dependent types to Go 3 though. :)

rogpeppe · 2021-06-11T09:02:08Z

Note that an alias is just an alternative name for a type, it's not a new type.

I'm not sure that this is entirely true. What about this, which is currently allowed?

type S1[V any] struct { .... }

type S2 = S1[int]

S2 neither an alternative name for an existing type nor an entirely new type. More of a composite type, perhaps. Also, it does have some identity of its own (its name is used when it's embedded)

Introducing a smaller set of type arguments (as suggested above), or providing stronger type constraints seems counter that idea. Such changes arguably define a new type and then one should do that: declare a new defined type, i.e., leave the = away

Sometimes defining a new type isn't possible. For example, if a type is specifically mentioned in a type signature, it's not possible to use a new type - you have to use the same type as the original. Also, the fact that all methods are lost when you define a new type is a real problem and embedding doesn't always work either.

For non-generic code, it might usually be possible to define a fully-qualified type alias like S2 above, but in generic code that's often not possible because a type parameter might be free.

An example:

Say some package defines an OrderedMap container that allows an arbitrary comparison operation for keys:

package orderedmap

type Map[K any, V any, Cmp Comparer[K]] struct {
    ...
}

func (m *Map[K, V, Cmp]) Clone() *Map[K, V, Cmp]

func (m *Map[K, V, Cmp]) Get(k K) (V, bool)

type Comparer[K any] interface {
    Cmp(k1, k2 K) int
}

I want to implement a higher level container in terms of orderedmap.Map. In my implementation, only the value type is generic:

package foo

type Container[V any] struct {
}

func NewContainer[V any]() *Container[V] {
    ...
   var m *orderedmap.Map[internalKey, V, keyComparer]
}

type internalKey struct {
    ...
}

type keyComparer struct{}

func (keyComparer) Cmp(k1, k2 internalKey) int {
    ...
}

In the above code, whenever I wish to pass around the orderedmap.Map[internalKey, V, keyComparer] type, I have to do so explicitly in full. This could end up very tedious (and annoying to change when refactoring the code). It would be nice to be able to do:

type internalMap[V any] = orderedmap.Map[internalKey, V, keyComparer]

Then we can avoid duplicating the type parameters everywhere.

Defining a new type wouldn't be great here - you'd either have to explicitly forward all the methods (if you did type internalMap[V any] orderedmap.Map[...]) or reimplement some of the methods (if you did type internalMap[V any] struct {orderedmap.Map[...]}).

In short, I'm fairly sure that generic type aliases are going to be a much requested feature when people start using generics in seriousness, and that they're definitely worth considering now even if they're not implemented, so that the type checker isn't implemented in a way that makes it hard to add them later.

rsc · 2021-08-18T18:13:46Z

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

beoran · 2021-08-18T20:11:27Z

I think we have to consider what exactly an alias is in Go language:

Alias declarations
An alias declaration binds an identifier to the given type.
AliasDecl = identifier "=" Type .
Within the scope of the identifier, it serves as an alias for the type.

Since an alias is an identifier, that is, in essence, a name, it does not make sense for such a name to have type parameters. An alias is simply a name for a type, not a type in itself. And names should not be parameterizable.

If it is desirable to define a new generic type based on an other generic type, this should be done using different syntax than a type alias.

Therefore I, respectfully oppose this proposal.

mdempsky · 2021-08-18T22:08:42Z

I think we have to consider what exactly an alias is in Go language:

We're discussing amending the Go language spec here, so I think referring to the current wording is somewhat begging the question. If we decide to amend the spec to allow type-parameterized aliases, then I think it's within scope to amend those sentences too.

If it is desirable to define a new generic type based on an other generic type, this should be done using different syntax than a type alias.

We have existing syntax for type aliases and for type parameters, and conveniently they're compatible. I don't see why we'd want to use a new syntax for type-parameterized aliases.

beoran · 2021-08-19T06:05:06Z

Well, the reason I refer to the current spec is because that explains what the current concept of am alias is. If we were to change the spec, the concept of what an alias is will also change quite radically. An alias will not be just a name for a type anymore. And I feel this will make Go quite a bit harder to learn.

Furthermore, I would say that the changing concept of an alias as a name to something else is at least not conceptually backwards compatible. With this proposal an alias is not just a name any more, but also a way to define types. Since the concept of this proposal is different, i feel the syntax should be different as well. Maybe just using := in stead of = for example.

jimmyfrasche · 2021-08-19T17:46:58Z

This would not let you define any new types: it would let you give a name to a subfamily of a family of types.

rsc · 2021-08-25T17:13:06Z

What is the concrete benefit that this would bring?
And is it necessary to have in Go 1.18, or should we wait until a future release?

gazerro · 2024-06-18T20:16:04Z

@griesemer Thanks, I wasn't sure if it was more appropriate to write the issue here or to create a new one.

griesemer · 2024-06-18T20:29:30Z

@gazerro As this is an accepted proposal that's already implemented (as a GOEXPERIMENT), a separate issue makes it easier to track it, as it's a bug that needs to be fixed. But reporting in the first place is great, so thanks.

gopherbot · 2024-06-20T16:07:06Z

Change https://go.dev/cl/593715 mentions this issue: cmd/compile: support generic alias type

Type parameters on aliases are now allowed after #46477 accepted. Updates #46477 Fixes #68054 Change-Id: Ic2e3b6f960a898163f47666e3a6bfe43b8cc22e2 Reviewed-on: https://go-review.googlesource.com/c/go/+/593715 Reviewed-by: Robert Griesemer <[email protected]> Reviewed-by: Matthew Dempsky <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Auto-Submit: Robert Griesemer <[email protected]>

gopherbot · 2024-06-20T18:39:08Z

Change https://go.dev/cl/593797 mentions this issue: [release-branch.go1.23] cmd/compile: support generic alias type

Type parameters on aliases are now allowed after #46477 accepted. Updates #46477 Fixes #68054 Change-Id: Ic2e3b6f960a898163f47666e3a6bfe43b8cc22e2 Reviewed-on: https://go-review.googlesource.com/c/go/+/593715 Reviewed-by: Robert Griesemer <[email protected]> Reviewed-by: Matthew Dempsky <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Auto-Submit: Robert Griesemer <[email protected]> Reviewed-on: https://go-review.googlesource.com/c/go/+/593797 Reviewed-by: Michael Pratt <[email protected]>

Type parameters on aliases are now allowed after golang#46477 accepted. Updates golang#46477 Fixes golang#68054 Change-Id: Ic2e3b6f960a898163f47666e3a6bfe43b8cc22e2 Reviewed-on: https://go-review.googlesource.com/c/go/+/593715 Reviewed-by: Robert Griesemer <[email protected]> Reviewed-by: Matthew Dempsky <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Auto-Submit: Robert Griesemer <[email protected]>

bobg · 2024-07-23T18:04:52Z

For the record, I think it's a mistake to publish iter before generic type aliases are ready.

iter.Seq and iter.Seq2 really want to be aliases. Please see @dominikh's comment here, and @adonovan's followup observation that they cannot later be alias-ified.

There's also the issue I commented on here, which applies to iter.Pull (and iter.Pull2) in addition to the slices.Collect example I gave. It too arises from Seq and Seq2 being distinct named types instead of aliases.

gopherbot · 2024-07-23T19:05:40Z

This issue is currently labeled as early-in-cycle for Go 1.24.
That time is now, so a friendly reminder to look at it again.

gopherbot · 2024-07-25T10:31:55Z

Change https://go.dev/cl/601115 mentions this issue: types2, go/types: fix instantiation of named type with generic alias

gopherbot · 2024-07-26T03:12:56Z

Change https://go.dev/cl/601235 mentions this issue: go/types/objectpath: support parameterized type aliases

The typechecker is assuming that alias instances cannot be reached from a named type. However, when type parameters on aliases are permited, it can happen. This CL changes the typechecker to propagate the correct named instance is being expanded. Updates #46477 Fixes #68580 Change-Id: Id0879021f4640c0fefe277701d5096c649413811 Reviewed-on: https://go-review.googlesource.com/c/go/+/601115 Auto-Submit: Robert Griesemer <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Robert Griesemer <[email protected]> Auto-Submit: Cuong Manh Le <[email protected]>

gopherbot · 2024-07-26T16:07:54Z

Change https://go.dev/cl/601116 mentions this issue: [release-branch.go1.23] types2, go/types: fix instantiation of named type with generic alias

…type with generic alias The typechecker is assuming that alias instances cannot be reached from a named type. However, when type parameters on aliases are permited, it can happen. This CL changes the typechecker to propagate the correct named instance is being expanded. Updates #46477 Fixes #68580 Change-Id: Id0879021f4640c0fefe277701d5096c649413811 Reviewed-on: https://go-review.googlesource.com/c/go/+/601115 Auto-Submit: Robert Griesemer <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Robert Griesemer <[email protected]> Auto-Submit: Cuong Manh Le <[email protected]> Reviewed-on: https://go-review.googlesource.com/c/go/+/601116

This change caused objectpath to treat Alias nodes more like Named types: as first-class nodes, with type parameters, and a destructuring operation (Alias.Rhs(), opRhs, encoded 'a') access the RHS type. A number of historical bugs made this trickier than it should have been: - go1.22 prints Alias wrongly, requiring a workaround in the test. - aliases.Enabled is too expensive to call in the decoder, so we must trust that when we see an opRhs and we don't have an alias, it's because !Enabled(), not a bug. - legacy aliases still need to be handled, and order matters. - the test of parameterized aliases can't be added until the GOEXPERIMENT has gone away (soon). Updates golang/go#46477 Change-Id: Ia903f81e29fb7dbb6e17d1e6a962fad73b3e1f7b Reviewed-on: https://go-review.googlesource.com/c/tools/+/601235 LUCI-TryBot-Result: Go LUCI <[email protected]> Auto-Submit: Alan Donovan <[email protected]> Reviewed-by: Tim King <[email protected]> Commit-Queue: Alan Donovan <[email protected]>

gopherbot · 2024-08-07T18:14:04Z

Change https://go.dev/cl/603935 mentions this issue: x/tools: updates for parameterized type aliases

gopherbot · 2024-08-09T21:28:17Z

Change https://go.dev/cl/604615 mentions this issue: go/types: remove GOEXPERIMENT=aliastypeparams

Type parameters on aliases are now allowed after golang#46477 accepted. Updates golang#46477 Fixes golang#68054 Change-Id: Ic2e3b6f960a898163f47666e3a6bfe43b8cc22e2 Reviewed-on: https://go-review.googlesource.com/c/go/+/593715 Reviewed-by: Robert Griesemer <[email protected]> Reviewed-by: Matthew Dempsky <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Auto-Submit: Robert Griesemer <[email protected]> Reviewed-on: https://go-review.googlesource.com/c/go/+/593797 Reviewed-by: Michael Pratt <[email protected]>

gopherbot · 2024-09-20T18:57:22Z

Change https://go.dev/cl/614638 mentions this issue: internal/aliases: remove Alias and Unalias

These two declarations can now safely be accessed directly from go/types. Also, remove all mention of internal/aliases from gopls/... We can enable two suppressed tests now that go1.23 is assured. Updates golang/go#46477 Change-Id: I9ae8536b0d022e3300b285547c18202bed302cf2 Reviewed-on: https://go-review.googlesource.com/c/tools/+/614638 LUCI-TryBot-Result: Go LUCI <[email protected]> Commit-Queue: Tim King <[email protected]> Reviewed-by: Tim King <[email protected]>

gopherbot · 2024-10-01T22:38:48Z

Change https://go.dev/cl/616816 mentions this issue: spec: document that alias declarations can have type parameters with 1.24

…1.24 For #46477. Change-Id: Id02d8f67fe82228bab3f26b1cb4ebd6ee67c4634 Reviewed-on: https://go-review.googlesource.com/c/go/+/616816 Reviewed-by: Ian Lance Taylor <[email protected]> Auto-Submit: Robert Griesemer <[email protected]> Reviewed-by: Rob Pike <[email protected]> Reviewed-by: Robert Griesemer <[email protected]> TryBot-Bypass: Robert Griesemer <[email protected]>

griesemer · 2024-10-23T18:25:31Z

@timothy-king Is there anything left to do here or can this be closed?

timothy-king · 2024-10-24T01:25:40Z

There are follow-ups on x/ repos to do (#69772) but nothing blocking. Let's close this.

mdempsky added the Proposal label Jun 1, 2021

mdempsky added this to the Go1.18 milestone Jun 1, 2021

ianlancetaylor added the generics Issue is related to generics label Jun 8, 2021

ianlancetaylor mentioned this issue Jun 29, 2021

[dev.fuzz] testing: use generics with testing.F #46890

Closed

bobg mentioned this issue Jul 24, 2024

New API for Go 1.23 bobg/go-generics#17

Closed

adonovan mentioned this issue Jul 27, 2024

cmd/compile: allow parameterized type aliases to omit redundant type parameters #68617

Open

timothy-king mentioned this issue Aug 7, 2024

exportdata: support type parameterized aliases #68778

Closed

19 tasks

timothy-king mentioned this issue Aug 28, 2024

x/build: add tip builders with GOEXPERIMENT=aliastypeparams=1 for at least go and x/tools repo #69121

Closed

timothy-king mentioned this issue Oct 3, 2024

all: audit x/ repos for gotypesalias settings #69772

Open

timothy-king closed this as completed Oct 24, 2024

spec: generics: permit type parameters on aliases #46477

spec: generics: permit type parameters on aliases #46477

Comments

mdempsky commented Jun 1, 2021

findleyr commented Jun 1, 2021 • edited Loading

mdempsky commented Jun 1, 2021

griesemer commented Jun 1, 2021 • edited Loading

bcmills commented Jun 1, 2021

bcmills commented Jun 1, 2021 • edited Loading

jimmyfrasche commented Jun 1, 2021

mdempsky commented Jun 1, 2021

findleyr commented Jun 1, 2021 • edited Loading

bcmills commented Jun 1, 2021

neild commented Jun 2, 2021 • edited Loading

griesemer commented Jun 2, 2021 • edited Loading

griesemer commented Jun 2, 2021 • edited Loading

neild commented Jun 2, 2021

griesemer commented Jun 2, 2021 • edited Loading

mdempsky commented Jun 2, 2021 • edited Loading

findleyr commented Jun 2, 2021 • edited Loading

mdempsky commented Jun 2, 2021

rogpeppe commented Jun 11, 2021

rsc commented Aug 18, 2021

beoran commented Aug 18, 2021

mdempsky commented Aug 18, 2021

beoran commented Aug 19, 2021

jimmyfrasche commented Aug 19, 2021

rsc commented Aug 25, 2021

gazerro commented Jun 18, 2024 • edited Loading

griesemer commented Jun 18, 2024

gopherbot commented Jun 20, 2024

gopherbot commented Jun 20, 2024

bobg commented Jul 23, 2024 • edited Loading

gopherbot commented Jul 23, 2024

gopherbot commented Jul 25, 2024

gopherbot commented Jul 26, 2024

gopherbot commented Jul 26, 2024

gopherbot commented Aug 7, 2024

gopherbot commented Aug 9, 2024

gopherbot commented Sep 20, 2024

gopherbot commented Oct 1, 2024

griesemer commented Oct 23, 2024

timothy-king commented Oct 24, 2024

findleyr commented Jun 1, 2021 •

edited

Loading

griesemer commented Jun 1, 2021 •

edited

Loading

bcmills commented Jun 1, 2021 •

edited

Loading

findleyr commented Jun 1, 2021 •

edited

Loading

neild commented Jun 2, 2021 •

edited

Loading

griesemer commented Jun 2, 2021 •

edited

Loading

griesemer commented Jun 2, 2021 •

edited

Loading

griesemer commented Jun 2, 2021 •

edited

Loading

mdempsky commented Jun 2, 2021 •

edited

Loading

findleyr commented Jun 2, 2021 •

edited

Loading

gazerro commented Jun 18, 2024 •

edited

Loading

bobg commented Jul 23, 2024 •

edited

Loading