On Thu, Aug 20, 2020 at 11:54 PM Kurtis Rader <[email protected]> wrote:
>
> On Thu, Aug 20, 2020 at 10:40 PM burak serdar <[email protected]> wrote:
>>
>> What worries me is code like this:
>>
>> func f() any {
>> int *i
>> return i
>> }
>>
>> func main() {
>> if f()==nil {
>> ...
>> }
>> }
>>
>> Use of "any" makes it look like f returns an *int and f() is nil, but
>> it is not, because "any" is interface{}.
>>
>> I think "any" as a constraint is useful, like "comparable", but "any"
>> as a type is misleading.
>
>
> Isn't your example just a case of confusing a nil interface with a nil value
> inside a generic interface? How does requiring writing it as `func f()
> interface{} {` make the behavior any clearer?
The point I was trying to make is that "any" as a constraint is better
than "interface{}" as a constraint, but "interface{}" as a type is
better than "any" as a type.
interface{}, when used as a constraint, doesn't mean than the value
has to be an interface{}, it means the value can be anything.
interface{}, when used as a value, doesn't mean that the value can be
anything, it means that the value is an interface, and you have to get
the value from that interface. Different uses, different identifiers.
I would be more comfortable if "any" was only a constraint instead of
an alias for interface{}. If your code needs it, you can still define
it. But if it is there, people will use it even if they can do without
it.
That said, I think the generics design draft looks great.
>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAMV2RqrVLzZ-mz9m2_RKVhybiGt2cPU1yKs-VB_d2nO3BO2qJg%40mail.gmail.com.
