Adds Option for codeintel#63637
Conversation
| func (o Option[A]) Unwrap() A { | ||
| val, ok := o.Get() | ||
| if !ok { | ||
| panic("called Option.Unwrap on None") | ||
| } | ||
| return val | ||
| } | ||
|
|
||
| func (o Option[A]) UnwrapOr(defaultValue A) A { | ||
| val, ok := o.Get() | ||
| if !ok { | ||
| return defaultValue | ||
| } | ||
| return val | ||
| } | ||
|
|
||
| func (o Option[A]) UnwrapOrElse(defaultValue func() A) A { | ||
| val, ok := o.Get() | ||
| if !ok { | ||
| return defaultValue() | ||
| } | ||
| return val | ||
| } | ||
|
|
||
| func (o Option[A]) Or(other Option[A]) Option[A] { | ||
| if o.IsSome() { | ||
| return o | ||
| } | ||
| return other | ||
| } | ||
|
|
||
| func (o Option[A]) OrElse(other func() Option[A]) Option[A] { | ||
| if o.IsSome() { | ||
| return o | ||
| } | ||
| return other() | ||
| } |
There was a problem hiding this comment.
(non-blocking suggestion) API-wise, I would rather introduce methods outside the "basic" set on an as-needed basis rather than right away. For example, I don't think OrElse is going to be that readable at usage sites because anonymous functions cannot have their types inferred
There was a problem hiding this comment.
What would you consider the "basic" set? I personally think the lazy getter variants are required in a strict language, but I could be convinced that Or and OrElse don't need to be here from the start.
There was a problem hiding this comment.
I'm with Varun on this one - ergonomics of Go's generics and lack of true lazy values probably rules out Or and OrElse being used often
There was a problem hiding this comment.
The "basic" set would probably be: Get() -> (T, bool), Set(T) -> void, Unwrap() -> T, IsSome() -> bool, IsNone() -> bool, Equals(Option[T]) -> bool and Compare(Option[T]) -> int. We can always add stuff later.
There was a problem hiding this comment.
re: Equals and Compare. I don't think you can define these guys, because you can't add a comparable constraint on a method.
How would you expect Set to behave on a None?
There was a problem hiding this comment.
Actually... I'd disagree that any implementation of Set would be a good idea. Options whole point here is to let us make it clear when a *T is about perf/mutability (same thing imo) instead of optionality.
There was a problem hiding this comment.
How would you expect Set to behave on a None?
It would mutate the underlying value. Rust has this too, but it's called insert. https://doc.rust-lang.org/std/option/enum.Option.html#method.insert
Adds an
Option[A any]type for codeintelTest plan
Added Unit and PB tests