Operator constraints in Go

Re:Operator constraints in Go by lalaithion on Monday May 23, 2022 @04:15PM (#31484284)

For a function, it makes sense to just write two functions, the easiest to use, and the one with maximum flaxibility.

    func SortOrdered[T constraints.Ordered](s []T) {
      // …
    }

    func Sort[T any](s []T, less func(T, T) bool) {
      // …
    }

For a data structure, I recommend using

    type SearchTree[T any] struct {
      Less func(T, T) bool
      // …
    }

and then writing two constructors

    func NewSearchTree(less func(T, T) bool) *SearchTree[T] {
      // …
      return &SearchTree[T]{
        Less: less,
        // …
      }
    }

    func NewOrderedSearchTree[T constraints.Ordered]() *SearchTree[T] {
      // …
      return &SearchTree[T]{
        Less: func(x, y T) bool {return x < y},
        // …
      }
    }

[ Parent | on HN ]

Re:Operator constraints in Go by Merovius on Monday May 23, 2022 @04:21PM (#31484347)

Personally, I very much dislike that this makes the zero value of `SearchTree[T]` not useful. I personally feel that anything which only handles data (as opposed to something like an os.File) shouldn't require explicit initialization.

I genuinely think I might personally converge on the `Comparator[T]` approach only (at least for types), for that reason.

[ Parent | on HN ]