Can NewVersion() return a *Version? about semver

[mark-kubacki]

I've not been 100% sure when to use a pointer and when not. And, as far as I remember, Go manages structs as pointers anyway; and by this—perhaps flawed—understanding returning a pointer to struct would indeed be using a double-pointer, and indirect reference (**T in C).

Usage of pointers as wanted by func (t *Version) f()… would be kinda flattened by the compiler anyway. This in mind I failed to see any benefits to func (t T) f()… and went with the former.

[mark-kubacki]

Sure! Same goes for whenever you see opportunities to improve the interface.

[mholt]

Actually, nevermind -- it creates allocations in the benchmarks which are currently 0, and slows it down by about 20ns. I'll just handle the referencing when needed. Thanks!

[mark-kubacki]

Turns out I've been wrong: The compiler won't flatten any pointers or optimize this in any way. (With the exception of &T for a f(… *T), and arrays.)

That's the why for version 3: value receivers where possible. If you (or someone else reading this) doesn't like it, keep importing version 2 and do reach out. I'll consider any back-porting if v2 is not too old by then. It's not that there are any other big functional changes between the two.

I've not made up my mind about whether to refactor any []*Version to []Version—which would then be grounds for releasing a version 4—for I need to learn the best solution for sorting and map-reduce. In any case, the pointer receiver to NextVersion can and will be replaced come the next minor revision in v3 (I don't see why anyone would call NextVersion∙NextVersion).