I was similarly confused. The patterns look very similar to those used in some other languages (at least superficially), so would have been useful to know why those were considered bad.
As a casual Go user, it wasn't obvious whether those particular implementations were bad, whether the patterns themselves are a bad fit for the Go language, or whether there was just a better (more Go-like) way of doing things.
I think the Option example (despite being the one the author thinks may actually be useful) is the worst one, since it really only replaces existing pointer syntax with named functions, but offers nothing else (well, maybe the Take() call?)
A better function to add to Optional[T] / *T would have been Map:
func Map[T any, V any] (o *T, foo func (T) V) *V {
if o == nil {
return nil
}
v := foo(*o)
return &v
}
or, with Optional:
func Map[T any, V any] (o Optional[T], foo func (T) V) Optional[V] {
if o.IsNone() {
return Optional[V]{}
}
return Optional[V]{foo(o.Yank())}
}
As a casual Go user, it wasn't obvious whether those particular implementations were bad, whether the patterns themselves are a bad fit for the Go language, or whether there was just a better (more Go-like) way of doing things.