I don't want to include int or struct{} in this case. I care specifically
about "can be compared to nil"
The only thing I can do with a type parameter that is only constrained as
"nil" is compare it to nil, or assign nil to it.
This means approximately "any reference type" -- interfaces, pointers,
maps, slices, chans...
But, let's put this out there:
How would you, today, write a function that compacted a slice of interface,
such that any "nil" interface value would be removed from the slice?
func Compact[T ?](sl []T) []T {
j := 0
for i := 0; i < len(sl); i++ {
if el := sl[i]; el != nil {
sl[j] = el
j++
}
}
return sl[:j]
}
There's nothing today I can put in place of the "?" to make this
perfectly-reasonable generic function work.
I propose I should be able to 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." -- Thomas
Jefferson
On Mon, Oct 2, 2023 at 9:26 PM Axel Wagner <axel.wagner...@googlemail.com>
wrote:
> It doesn't solve the problem. That function signature you wrote could not
> be instantiated by `int`, for example. You can't write `comparable | nil`,
> as `comparable` is not allowed in a union. And if we allowed it, there
> would be no way to write the body of the function. It doesn't help with
> types like `struct{ F func() }`. And it doesn't make it easier to write the
> zero value for returns etc. And it doesn't address the same kind of issue
> for generated code.
>
> On Tue, Oct 3, 2023 at 3:51 AM Jon Watte <jwa...@gmail.com> wrote:
>
>> 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 []T) ...
>>
>> Sincerely,
>>
>> Jon
>>
>>
>> On Mon, Oct 2, 2023, 16:53 Ian Lance Taylor <i...@golang.org> wrote:
>>
>>> There is a lot more on this topic at https://go.dev/issue/61372.
>>> We're not sure how best to handle it.
>>>
>>> Ian
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CAJgyHGPRdv%3DjOPs34V1Q%3DNh9RVpD8c-qagr%3DdEz0OX-oDEaa7Q%40mail.gmail.com
>> <https://groups.google.com/d/msgid/golang-nuts/CAJgyHGPRdv%3DjOPs34V1Q%3DNh9RVpD8c-qagr%3DdEz0OX-oDEaa7Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAJgyHGMV%2BhF%3Dvfm7SLigHa8ZAh5tK28eKkBzQ9iu-FVw9J4MAQ%40mail.gmail.com.
