represent encoded samples as separate type (EncodedSamples)

[ericphanson]

rather than having a flag in the struct itself. I think promoting to the type domain makes sense bc very little code is agnostic to whether or not it is encoded, and many methods only make sense for decoded ones. This can prevent a class of errors where the flag isn't checked when it should be (by instead getting MethodErrors). Also it is easy to add methods like f(s::EncodeSamples) = f(decode(s)) when desired.

[kleinschmidt]

I think one potential downside to this is aliasing, since decode does not always allocate new storage (esp. if the offset/resolution are 0/1). So there would still be some footguns here, but still probably better than the status quo

[ericphanson]

Imo aliasing is basically fine, it just has to be documented. Eg “!!! warning” with “Output may share data with input data” (ideally with exactly when if we can commit to something).

[jrevels]

xref'ing #77 as breadcrumb for future me