though (there's a
reason they aren't comparable!) and making everything comparable to nil
without type qualification is better IMO.
Sincerely,
Jon Watte
--
"I find that the harder I work, the more luck I seem to have." -- Thomas
Jefferson
On Tue, Oct 17, 2023 at 10:25 PM Axel
m.
That might indeed be a good solution -- but if so, it'd be nice to know
what we can do to make that happen, and what the other opposition to that
change might be, because that change also feels much less narrow than a
"nil" type constraint.
Sincerely,
Jon Watte
--
"
e!
return nope
}
return val
}
func MaybeNuke(T any](b bool, val T) T {
if b {
return zero[T]{} // maybe? seems weird
}
return val
}
This is because not all zero values can be instantiated inline with simply
T{}.
Sincerely,
Jon Watte
--
"I find that the harder I work, the more lu
uot;can be compared or assigned to
nil," then that clearly should be expressible in the generic type system,
unless you for some reason want the the generic type system to be
deliberately less expressive than the full type system, and deliberately
want to exclude use cases like these.
Sincerely,
these kinds of affordances are typically a
little more involved, but we would save a lot of boilerplate/repeated code
if this constraint were available.)
(Also, Infallible() could be a good standard library function, because it's
common enough, but that's a totally different discussion t
o put "nil" in place of the "?" to make this
work, and it would work for any reference type (that can be compared or
assigned to nil.)
Unless I'm missing something?
Sincerely,
Jon Watte
--
"I find that the harder I work, the more luck I seem to have." -- Thom
What's the concern with "a constant interface that is inhabited exactly by
the types that can compare to nil?"
This is clearly something the language has as a concept -- it knows whether
"foo == nil" is an error or not.
"nil" could be the ergonomic name for this constraint:
func Compact[T nil](s
nto "zero values" or "comparables," but it's a pretty
basic fundament of the runtime, so having to special-case everything about
it is quite frustrating and cumbersome.
Sincerely
Jon Watte
On Thursday, December 22, 2022 at 5:39:29 AM UTC-8 Axel Wagner wrote:
