3 ms·
The database/sql package gained native support[1] for the uuid.UUID type so it will Just Work even without the methods. This probably should have been mentioned
by agwa 2mo ago
The database/sql package gained native support[1] for the uuid.UUID type so it will Just Work even without the methods. This probably should have been mentioned in the release notes and database/sql package docs.
[1] https://cs.opensource.google/go/go/+/refs/tags/go1.27.0:src/database/sql/convert.go;l=270-280 https://cs.opensource.google/go/go/+/refs/tags/go1.27.0:src/...
- semiquaver 2mo agoDoesn’t the type name uuid.UUID violate go’s style guide for type naming? I seem to recall a fairly specific prohibition on stutter-types.
- coder543 2mo agoNo. What else could it reasonably be named? Hard to imagine. The rule has always been intended to cover types that have another word in them but still choose to pointlessly repeat the package name. `uuid.UUIDGenerator` is a hypothetical example of the anti-pattern that would instead be better named as `uuid.Generator`.
- whateveracct 2mo ago> No. What else could it reasonably be named? Hard to imagine. Ocaml often just has it be T so uuid.T
- tomjakubowski 2mo agouuid.Entifier
- kbolino 2mo agoRepeating the package name is fine if it's exactly the same name (modulo capitalization) and there's nothing better to name the type anyway. The style issue would arise with e.g. uuid.UUIDVersion, which should just be named uuid.Version. There used to be a gopls lint that would flag names like uuid.UUID but it got relaxed awhile ago.
- markusw 2mo agoYeah, I would have gone with uuid.V4 or something. But oh well, as long as it works. :D
- dolmen 2mo agoV4 or V7 are just how you initialize them (constructor), but then this the same representation, so they don't need specific types.
- ungerik 2mo agoThat's why we called ours uu.ID https://pkg.go.dev/github.com/domonda/go-types@v0.0.0-20260729180939-e46a43f4284c/uu#ID https://pkg.go.dev/github.com/domonda/go-types@v0.0.0-202607...