Per the discussion in #54, this introduces a NullUUID type to the package that works like other nullable types in the database/sql package. Figured I'd just get the PR out while I'm playing around in this space.

In order to use Go Dep effectively with semver, please release or tag a new version. Using revisions with many open source project dependencies makes Go Dep much less convenient. The latest version is roughly 1 year and 22 commits in the past thus I could argue a new version is likely. It also seems lately new features were thus further strengthen the idea to bump the version.

The SQL Value() gives a string representation of UUID, if this is unindexed data this may make little difference in the performance of the data but where this is either an index or even the PK this not efficient storage. Here's one of many articles on it.

This could either have a breaking change and make this provide a []byte type. If there is some more dominant SQL DB being targeted which does not benefit from this, then we could minimally have a BytesValuer() function to return a Valuer which does do this.

Adds a Version4 factory struct, which can accumulate options for generating version 4 UUIDs. For now the only option is the io.Reader used for randomness.

Also reverts #80, as that implementation cannot be used safely in general. Instead, clients should create a factory with a buffered io.Reader implementation.

Fixes #86.

cc @pborman

I'm getting the following test failures with Golang 1.10:

=== RUN   TestNode
--- FAIL: TestNode (0.00s)
        uuid_test.go:306: NodeInterface returned an empty string
=== RUN   TestNodeID
--- FAIL: TestNodeID (0.00s)
        uuid_test.go:376: NodeInterface "user" after SetInteface

Would it be possible/desirable to support parsing empty strings in JSON as uuid.Nil?

Currently it generates "invalid UUID length: 0": https://play.golang.org/p/K4y-DFj44Z6

My online app is use this lib by uuid.New(), About 3 million concurrent I found per call of uuid.New() cost more than 9 minutes. I found many mutex in it's call chain. Is there any problems?

This significantly improves the speed of failed parses due to wrong lengths. Previously the fmt.Errorf call dominated, making this the most expensive error and more expensive than successfully parsing:

BenchmarkParse-4                 29226529        36.1 ns/op
BenchmarkParseBadLength-4         6923106       174 ns/op
BenchmarkParseLen32Truncated-4   26641954        38.1 ns/op
BenchmarkParseLen36Corrupted-4   19405598        59.5 ns/op

When the formatting is not required and done on-demand, the failure per se is much faster:

BenchmarkParse-4                 29641700        36.3 ns/op
BenchmarkParseBadLength-4        58602537        20.0 ns/op
BenchmarkParseLen32Truncated-4   30664791        43.6 ns/op
BenchmarkParseLen36Corrupted-4   18882410        61.9 ns/op

Add benchmarks for different kinds of invalid UUIDs, and a test case for too-short UUIDs to ensure visible behavior doesn’t change.

Typos

'from' is repeated twice in this comment:

https://godoc.org/github.com/google/uuid#NewRandom

A note about uniqueness derived from from the UUID Wikipedia entry:

NewRandom() returns an error, not a panic:

https://godoc.org/github.com/google/uuid#NewRandom

NewRandom returns a Random (Version 4) UUID or panics.

Why does New panic?

It is surprising New() panics when compared to the html/template package, for example, where functions that panic include the word Must:

var t = template.Must(template.New("name").Parse("html"))

https://godoc.org/github.com/google/uuid#New

New ~is~ creates a new random UUID or panics. New is equivalent to the expression

I am working on a legacy app that used UUID v4 as its authentication key. Is that secure? (Some implementations, like python3's are secure, meanwhile others aren't)

Moving the entire app to crytpo/rand would be way too much.

Related to issue #43. To enable concurrent and re-creatable usage, I have added a UuidSource, similar to the source in math/rand. It holds its own random number generator (the rander). I have added only the methods that seemed relevant: SetRand(), NewRandom() (version 4) and New(). From what I saw, other methods do not use random number generator (except the clock sequence but this can't be recreated anyway).

uuid.Nil https://github.com/google/uuid/blob/44b5fee7c49cf3bcdf723f106b36d56ef13ccc88/hash.go#L19 has the documentation Well known namespace IDs and UUIDs (see image below) but it should probably be empty UUID, all zeros

In the current implementation, the generation of version 1 UUIDs using distinct node ids is only possible by sequentially calling "SetNodeID(…); NewUUID()" for each UUID to generate. There also is no sort of locking for this workflow, so we might experience race conditions when generating UUIDs for distinct node ids simultaneously.

Additionally RFC-4122 section 4.5 suggests to set the u/m bit to 1, when using custom node ids in order to reliably avoid collisions with UUIDs created for node ids which are based on IEEE 802 addresses. This is not (and should not being) checked within the global SetNodeID(...) func.

So I decided to add a CustomNodeId type which enables this kind of usage in a clean way.

Must(Parse("xxxx")) is considered legacy code to forced uuid to parse because the code is pre-implementation of Must(Parase("xxxx"))(https://github.com/google/uuid/pull/26)

This one is simpler.

Hi! I noticed there is a uuid.Nil for UUID v1 but no uuid.Nil (for example uuid.Nil4) for UUID v4 could be useful adding this method to the library? (I could also make a PR)