valuewrapper can be used only to generate atomic wrapper types for
types which are stored as atomic.Value. This isn't necessary because the
same logic can be applied to atomic wrappers built on other types like
Duration and Bool.
Generalize valuewrapper into atomicwrapper with support for optional
pack/unpack functions which handle conversion to/from `interface{}`.
This lets Error hook in and install the `storedError` struct (now called
`packedError`) to avoid panics from nil storage or value type change.
Generated files should contain the following comment in the first few
lines for them to be considered generated by GitHub.
Code generated by <executable>
The additional `@generated` tag does the same for Phabricator.
Rather than hand-writing wrappers around atomic.Value, generate them
automatically from the same template. The generator is at
internal/gen-valuewrapper. The generator correctly handles generating
wrapper structs for nillable types.
Since String holds textual information, instead of implementing
json.Marshaler and json.Unmarshaler, we should implement
encoding.TextMarshaler and encoding.TextUnmarshaler on String.
This makes it encodable and decodable using a variety of formats
including JSON, XML, YAML, and TOML.
Support serializing and deserializing atomic objects to/from JSON using
the JSON representation of the underlying types. Without this,
marshaling returns `{}`.
Per discussion in #68, `atomic.Value` does not yet implement support
because there's an open question as to whether it should implement it
even if the underlying type doesn't support JSON marshaling/
unmarshaling.
Resolves#49
This optimization causes data races since we're changing the value field
without using atomics. E.g., a caller who has multiple goroutines
calling `Set("1")` and `Set("")` will race on the access to `s.v` since
one goroutine is trying to read it while the other sets it, neither
using atomic operations.
This reverts commit 16b44f14f0.
Unexported field name means the methods on different types look
more similar (e.g., &i.v instead of &i.int32 or &i.uint32).
For String, this is important since we don't want users to be
able to access the underlying atomic.Value
