Unfortunately for people SELECTing UUIDs out of a DB directly into a uuid struct, the built-in uuid structs don't implement the necessary interface for that, so you'll have to continue using the google package, or a plain string.

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/...

Doesn’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.

Repeating 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.

No. 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`.

> No. What else could it reasonably be named? Hard to imagine.

Ocaml often just has it be T

so uuid.T

uuid.Entifier

Yeah, I would have gone with uuid.V4 or something. But oh well, as long as it works. :D

V4 or V7 are just how you initialize them (constructor), but then this the same representation, so they don't need specific types.

That's why we called ours uu.ID

https://pkg.go.dev/github.com/domonda/go-types@v0.0.0-202607...

uuid.UUID is implemented as [16]byte, like most other UUID implementations out there.

If you want to keep your package implementation agnostic, use [16]byte as argument type; that's assignment-compatible with any other type that is such an array underneath:

For an example, see the UUID logging of golog: https://pkg.go.dev/github.com/domonda/golog#Message.UUID

Or just a number (128-bit).

Oooof… well played go team, well played.

will 'go fix' take care of this?

I don't think it ever suggests anything specific to 3rd-party packages