make LessThan, Equal and Compare accept a pointer type

[alexanderwilling]

For usability, it would be nice if one could pass a *semver.Version to LessThan(), Equal(), and Compare(). Is there something preventing this? And why are those methods defined on a value receiver instead of a pointer receiver?

[jonboulle]

Why do you think this'd help usability? It's pretty trivial to dereference inline during the call (e.g. `foo.Compare(*bar)`) As to why value vs pointer - I think it clearly distinguishes that the methods are non-mutating and the type is trivial enough that I don't think the copy overhead should be concerning. Generally seems like we're conforming with the idiomatic go guidance: https://golang.org/doc/faq#methods_on_values_or_pointers

…

On 20 December 2016 at 15:36, alexanderwilling ***@***.***> wrote: For usability, it would be nice if one could pass a *semver.Version to LessThan(), Equal(), and Compare(). Is there something preventing this? And why are those methods defined on a value receiver instead of a pointer receiver? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#20>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACewN6Gylzh6AyRJNpfaC65m_wOztiHvks5rJ-f3gaJpZM4LR5r2> .

[alexanderwilling]

Because right now, I can't write for example foo.Compare(semver.New("1.2.3")). I know, I could just use foo.String() == "1.2.3". But I think it would make sense to accept whatever type the "constructor" (New()) returns, especially as it comes at no cost.

Regarding the receiver type, the link you provided also says:

Next is consistency. If some of the methods of the type must have pointer receivers, the rest should too, so the method set is consistent regardless of how the type is used.

The go vet tool (or maybe go lint) even complains about differing receiver types.

[jonboulle]

Because right now, I can't write for example foo.Compare(semver.New("1.2.3")). I know, I could just use foo.String() == "1.2.3".

foo.Compare(*semver.New("1.2.3")) works fine

But I think it would make sense to accept whatever type the "constructor" (New()) returns,

Fair point, although arguably the current situation is a bit more flexible (because you can dereference inline but not reference inline).

Regarding the receiver type, the link you provided also says:

hoisted by my own petard ;-). IMO the current situation is still cleaner but if you feel really really strongly about it you could put up a PR

The go vet tool (or maybe go lint) even complains about differing receiver types.

Strange, I can't seem to reproduce