By the way, what is the idiomatic way to assert that a variable that is 
type constrained as "any" in the generic declaration, is in fact comparable 
(if there is a way)?

I.e., in my example "Foo" function, is there a way for me to further 
constrain (or rather, assert that) v's type is comparable, so that I can in 
fact do the comparison?

Constraining to comparable for a single function is typically not a 
hardship, but if you have a struct with a bunch of interface functions, 
most of which don't need comparable, but only one of which does, it'd be 
nice not to jump through declarative hoops to make that happen.

A.


On Wednesday, January 18, 2023 at 4:59:51 PM UTC-8 bse...@computer.org 
wrote:

> On Wed, Jan 18, 2023 at 5:52 PM Andrew Athan <andr...@gmail.com> wrote:
>
>> (Possibly related to issues such as those discussed in 
>> https://groups.google.com/g/golang-nuts/c/pO2sclKEoQs/m/5JYjveKgCQAJ ?)
>>
>> If I do:
>>
>> ```
>> func Foo[V any](v V)bool {
>>   return v==v
>> }
>> ```
>>
>> golang 1.19 reports:
>>
>> ```
>> invalid operation: v == v (incomparable types in type set)
>> ```
>>
>> There are two issues with this in my mind: (1) It is ambiguous in that I 
>> cannot be sure, as a new user, whether what's being indicated is an 
>> incompatibility between the actual types on either side of the equality 
>> test or between the set of possible types that COULD be on either side of 
>> the equality test due to V's any type constraing in either the case where 
>> the left and right side are same or different types (2) In this case, the 
>> type V appears to be determinable at compile time and yet it is claimed 
>> this equality test is in some way problematic.
>>
>> I'm sure I'm misunderstanding something about golang generics.
>>
>> Can someone comment on this?
>>
>> Thanks in advance :)
>>
>
>
> The problem here is that a type constraint is different from a type, but 
> the same identifier is overloaded in the language so "any" as a type 
> constraint means something else from "any" as a type.
>
> The error is there, because without that Foo([]string{}) would satisfy the 
> constraint but it is still a compile error. Foo[V comparable)(v V) bool is 
> the correct declaration.
>  
>
>>
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/7134400e-ed5e-4c9f-bacd-4b739daf0e0bn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/7134400e-ed5e-4c9f-bacd-4b739daf0e0bn%40googlegroups.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/414ec7ec-33af-492c-b4c6-ed3b807fbc7dn%40googlegroups.com.

Reply via email to