Open pherrymason opened 6 months ago
Because they are optional. The nil
value should be interpreted as "doesn't exist".
This should definitely be documented better...
Have you considered using an optional type? Like:
type Option[T any] struct {
value T
isSetted bool
}
func Some[T any](value T) Option[T] {
return Option[T]{value: value, isSetted: true}
}
func None[T any]() Option[T] {
return Option[T]{isSetted : false}
}
The project started before generics were available. It is definitely possible to switch, but ... for what it's worth, Go has nils. (Terrible design decision.) And nils are very often used for exactly this semantic intent. I don't love it, but it's common practice in Go (and other null-enabled languages) and I think changing this now may annoy current users of this library.
I'm ok with it!
Thank you for the discussion, it's useful. I'm not opposed to changing in the future. I will re-open this as an issue to document the use of nils, at the very least.
Thank you too. I'm not an expert with Go, explaining me the context allowed me to understand better the design.
What's the reasoning behind some
CompletionItem
members likeKind
,Details
,Deprecated
,Preselect
, etc... are defined as pointers?