This is a backwardly incompatible change, but I'm hoping that the release
is new enough and this feature obscure enough to avoid problems.
NewDecoderAtSection has often been problematic when trying to get tests
to pass. There are some awkward special cases in the code to deal with
it, and a fix for issue #43 was going to require more special cases.
The functionality NewDecoderAtSection provides is really overly general
for what's needed - I don't know of any concrete use case that requires
decoding just the fields of a line-protocol line, for example. In some
places, we might need to parse just the tags, but that can be implemented
by a much more specific entry point that won't interact oddly with the
rest of the decoding functionality.
So let's remove it, at least for now, which also allows us to remove the Section
type itself from public view, simplifying the API further.
This is a backwardly incompatible change, but I'm hoping that the release is new enough and this feature obscure enough to avoid problems.
NewDecoderAtSection
has often been problematic when trying to get tests to pass. There are some awkward special cases in the code to deal with it, and a fix for issue #43 was going to require more special cases.The functionality
NewDecoderAtSection
provides is really overly general for what's needed - I don't know of any concrete use case that requires decoding just the fields of a line-protocol line, for example. In some places, we might need to parse just the tags, but that can be implemented by a much more specific entry point that won't interact oddly with the rest of the decoding functionality.So let's remove it, at least for now, which also allows us to remove the
Section
type itself from public view, simplifying the API further.