Package level generics may look less confusing.
package abc(Key,Value)
contract CompileCheck(a1 Key, a2 Value) {
//...
}
type Pair struct {
K Key| package main | |
| import ( | |
| "math/rand" | |
| std "sort" | |
| "strconv" | |
| "testing" | |
| uno "github.com/peterrk/slices" | |
| exp "golang.org/x/exp/slices" |
| package main | |
| import ( | |
| "math/rand" | |
| stdsort "sort" | |
| "strconv" | |
| "testing" | |
| "github.com/peterrk/slices" | |
| ) |
| package main | |
| import ( | |
| "math/rand" | |
| stdsort "sort" | |
| "testing" | |
| "github.com/peterrk/slices" | |
| ) |
Package level generics may look less confusing.
package abc(Key,Value)
contract CompileCheck(a1 Key, a2 Value) {
//...
}
type Pair struct {
K Keyval, err := function()
if err != nil {
//handler codes...
}Error handling consists of 3 key parts, trigger, handler and binding rule. In Go 1, trigger is if err != nil, handler is a piece of code in {}, and binding rule is obvious. Handler holds the control flow switch.
Actually, I donot think error handling in Go 1 has any functional problem. The only problem is repetition, especially repetition of triggers. Go 1 allows us to place trigger and assignment in one line, but that does not really solve the problem.