You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Somewhere between type parameters entering `gotip` and `go1.18-rc1`, several things that were previously possible were made impossible. Most crucially, this includes that line 43 now causes the compiler to throw the error `cannot use a type parameter as RHS in type declaration`. I'm not sure what purpose prohibiting this behavior served, but it's probably for the best because I seriously don't think this is the best way to solve this problem. I much prefer Ian Lance Taylor's suggestion [here](https://github.com/golang/go/issues/47632#issuecomment-897168431), and I hope this is what the community eventually falls behind.
7
-
8
-
9
4
## What is this?
10
5
11
6
`lesser` defines a type-parameterized interface with one method, `Less`, which returns a boolean for whether the caller, of type `T`, is less than some other instance of `T`. This is blatantly stolen from [Robert Griesemer's talk at Gophercon 2020](https://www.youtube.com/watch?v=TborQFPY2IM) about the type parameters proposal. Probably more controversially, this library also defines a wrapper called `Basic` over the built-in numerical types, exposing the underlying `<` operator through this `Less` method. The reasoning for this follows.
12
7
13
8
## Why is this?
14
9
15
-
In the near future the standard library will, in a `constraints` package, have something like this (from [the type parameters proposal](https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#operations-based-on-type-sets)):
16
-
17
-
```go
18
-
// Ordered is a type constraint that matches any ordered type.
19
-
// An ordered type is one that supports the <, <=, >, and >= operators.
This is explicitly only suitable for built-in types since user-defined types (structs etc) may not respond to operators. Conversely, however, built-ins may not respond to methods. As a consequence, any sorting function or ordered collection must specify different versions (`BasicSort` vs `Sort`, `BasicHeap` vs `Heap`, etc) for built-in types and user-defined types. This is an untenable position, and makes the type parameters proposal insufficient and unworkable for a large swathe of the problems it exists to solve (anything involving ordering).
10
+
In the near future, [the `constraints` package](https://pkg.go.dev/golang.org/x/exp/constraints) will be in the standard library. Constraints defines an constraint called `Ordered`, which matches all types that respond to the `<` operator. This is explicitly only suitable for built-in types since user-defined types (structs, etc) may not respond to operators. Conversely, however, built-ins may not respond to methods. As a consequence, any sorting function or ordered collection must specify different versions (`BasicSort` vs `Sort`, `BasicHeap` vs `Heap`, etc) for built-in types and user-defined types. This is an untenable position, and makes the type parameters proposal insufficient and unworkable for a large swathe of the problems it exists to solve (anything involving ordering).
29
11
30
12
There appear to be three different possible directions to go here:
31
13
32
-
1. Every time you want to write an ordered collection or a sorting function or anything depending on natural ordering functionality, you have to copy paste it and have one copy use `Lesser` as the constraint and the other use `Ordered` as the constraint. That's not a reasonable request to make. Without this library or something like it ***you are here***. As of the end of last year this was Robert Griesemer's suggested solution, and to the best of my knowledge it still is.
14
+
1. Every time you want to write an ordered collection or a sorting function or anything depending on natural ordering functionality, you have to copy paste it and have one copy use `Lesser` as the constraint and the other use `Ordered` as the constraint. That's not a reasonable request to make. Without this library or something like it ***you are here***. As of the end of last year this was Robert Griesemer's suggested solution, and to the best of my knowledge it still is. It's unclear what the purpose of generics is if we're still going to be forced to use code generation or copy-pasting.
33
15
34
16
2. Write a library very much like this one, but which defines a series of wrappers for each of the built-in types, each of which has a `Less` method, so then when you want to use `int`s in an ordered collection you'd convert them all to `lesser.Int` first. This is scary and gives me serious Java heebie-jeebies. I do not want Go to turn into a world where we are all using special magic wrappers for every basic data type at all times or something.
35
17
36
-
3. Exactly what this library is, which is the same as the former but instead of defining the types manually, you create them at compile-time using type parameters with something like `lesser.Basic[int]` instead of `lesser.Int`. It feels far less likely this way that it'll develop into the scary situation I just described.
18
+
3. Exactly what this library is, which is the same as (2) but instead of defining the types manually, you create them at compile-time using type parameters with something like `lesser.Basic[int]` instead of `lesser.Int`. It feels far less likely this way that it'll develop into the scary situation I just described.
19
+
20
+
4.[SEE ADDENDUM](#addendum) FOR IAN LANCE TAYLOR'S EPIC AND COOL ALTERNATIVE
37
21
38
-
I don't know if something like this is coming to the standard library, but I'm unwilling to wait until it is. I have a sneaking suspicion the `Lesser` interface itself is likely to make it into the `constraints` library alongside `Ordered`, at which point I'll likely remove each of them here. This doesn't provide a Java-style `compareTo` or the like, but merely exposes a `Less` method that is fit for sorting algorithms and ordered collections. Look elsewhere for something more robust. This is a plug for a hole in the current generics implementation. This is not a "framework"; this is not a "platform".
22
+
I don't know if something like this is coming to the standard library, but I'm unwilling to wait until it is. For a while it felt like the `Lesser` interface itself was likely to make it into the `constraints` library, but I'm not sure about that now. All discussion of how the hell to actually use generics has been explicitly pushed until some time after generics are released into the wild. I hate the antichrist.
23
+
24
+
This doesn't provide a Java-style `compareTo` or the like, but merely exposes a `Less` method that is fit for sorting algorithms and ordered collections. Look elsewhere for something more robust. This is a plug for a hole in the current generics implementation. This is not a "framework"; this is not a "platform".
39
25
40
26
## How do I use it?
41
27
42
-
Well first you'll need to get Go 1.18, which might seem hard since it hasn't been released yet. You can get what amounts to the dev branch of the Go compiler using [`gotip`](https://pkg.go.dev/golang.org/dl/gotip):
28
+
Well first you'll need to get Go 1.18, which has not yet been released. Release candidate 1 was released in February, and you can install it as follows:
43
29
44
30
```bash
45
-
go install golang.org/dl/gotip@latest
46
-
gotip download
31
+
go install golang.org/dl/go1.18rc1@latest
32
+
go1.18rc1 download
47
33
```
48
34
49
-
Now you can use the `gotip` command as an alternative to the `go` command, but with generics enabled.
50
-
51
-
If you want to build this into your project, use `gotip` when updating or initializing your `go.mod`, or otherwise make sure that your `go.mod` notes that we're using `go 1.18`, and make sure you build or run with `gotip`, not `go`, or you'll get compiler syntax errors.
35
+
Now you can use the `go1.18rc1` command as an alternative to the `go` command, but with generics enabled.
52
36
53
37
## Okay, but how do I *use* it?
54
38
@@ -74,33 +58,41 @@ If you want to initialize the `Heap` we defined above for the built-in concrete
74
58
75
59
```go
76
60
varhHeap[lesser.Basic[int]]
77
-
h.Push(lesser.Basic[int](1))
78
-
h.Push(lesser.Basic[int](2))
79
-
h.Push(lesser.Basic[int](3))
61
+
h.Push(lesser.Basic[int]{1})
62
+
h.Push(lesser.Basic[int]{2})
63
+
h.Push(lesser.Basic[int]{3})
80
64
```
81
65
82
-
If you want to use it with your own wacky type, you won't need to (and can't) use `Basic`, since your own type won't implement `Ordered`. Instead, you can just do something like this:
66
+
To get the value back out of a `Basic`, you just poll the `Val` attribute. It used to be as simple as a cast back to the correct type, but then [this issue](https://github.com/golang/go/issues/45639) happened because we can't have nice things, so `Basic` had to be changed from an alias type to a struct. The ergonomics have suffered as a consequence.
67
+
68
+
If you want to use it with your own wacky type, `Basic` doesn't apply, since your own type won't implement `Ordered`. Instead, you can just give it a `Less` method.
83
69
84
70
```go
85
-
typeBookstruct {
86
-
Titlestring
87
-
ISBNuint64
71
+
typeNamestruct {
72
+
Laststring
73
+
Firststring
88
74
}
89
75
90
-
func(bBook) Less(otherBook) bool {
91
-
return p.ISBN < other.ISBN
76
+
func(thisName) Less(otherName) bool {
77
+
if this.Last == other.Last {
78
+
return this.First < other.First
79
+
}
80
+
return this.Last < other.Last
92
81
}
93
82
```
94
83
95
-
And now you should be able to directly push some `Book`s onto a heap of `Book`s.
84
+
And now you should be able to directly push some `Name`s onto a heap of `Name`s.
96
85
97
86
```go
98
-
varhHeap[Book]
99
-
h.Push(Book{"Cool Book", 1234567890123})
100
-
h.Push(Book{"Another Cool Book", 2345678901234})
101
-
h.Push(Book{"And Still Another Cool Book", 3456789012345})
87
+
varhHeap[Name]
88
+
h.Push(Name{"Marx", "Karl"})
89
+
h.Push(Name{"Marx", "Groucho"})
102
90
```
103
91
104
92
## Okay, but really, why?
105
93
106
94
I don't know if I really think this library is a good idea. I don't know how Go-y it is. The definition of """idiomatic""" Go will probably change in the coming year, and maybe this is the way things are going. I don't know how I feel about that. More than anything I want this library to get other people thinking about how this is actually going to work, because without something like this library it's not possible to make simple ordered collections that operate on both user-defined and built-in data types.
95
+
96
+
## Addendum
97
+
98
+
Ian Lance Taylor made (what I think is) a great suggestion [here](https://github.com/golang/go/issues/47632#issuecomment-897168431), arguing for constraining containers to `any` and passing a comparison function to the constructor. This is a good idea and subjectively feels more idiomatic than what I have done here. I think?
0 commit comments