Re: signatures vs sf-date

On Mon, Jan 23, 2023 at 03:23:15PM +0000, Lucas Pardue wrote:
> Hey,
> 
> On Mon, Jan 23, 2023 at 10:05 AM Julian Reschke <julian.reschke@gmx.de>
> wrote:
> 
> > On 23.01.2023 07:56, Mark Nottingham wrote:
> > >
> > >
> > >> On 19 Dec 2022, at 9:28 pm, Julian Reschke <julian.reschke@gmx.de>
> > wrote:
> > >>
> > >> This sort of confirms that we really need to figure out what the
> > >> expectations for users of SF (be it implementations or specifications)
> > >> are - is support of sf-date an extension you need to opt in somehow?
> > >
> > > Yes - by emitting or consuming a field that uses it.
> >
> > When I invoke an SF parser - how do I signal to the parser that I want
> > support for sf-date?
> >
> 
> For sf-date support in sfv, I'd expect there to be a new
> BareItern::Date enum added to the library. When parsing a field I
> expect to be a date, I'd do a similar pattern match in my app. Of
> course, I'd need to update my apps dependency to a library version
> that provided that enum otherwise my application wouldn't compile.
> 
> Should an update to the library include sf-date by default? I'm not
> sure. If I no longer get an error when I was expecting it, that might
> affect program flow. Its probably easier to reason about in Rust due
> to compiler checks. Since this is an additional type, I guess support
> could be stuck behind a feature flag, so that the old behaviour could
> be preserved if it was really necessary. The flag could be default on,
> or default off.

Unfortunately, the BareItem type is not marked as #[non_exhaustive],
which allows code like this to compile:

match some_bare_item {
 BareItem::Decimal(_) => 1,
 BareItem::Integer(_) => 2,
 BareItem::String(_) => 3,
 BareItem::ByteSeq(_) => 4,
 BareItem::Boolean(_) => 5,
 BareItem::Token(_) => 6,
}

... Which will then fail to compile if BareItem::Date got added (if it
was marked as non-exhaustive, then one would have to add wildcard match,
which would be invoked if the bare item was something unknown).

And feature flags will not help here, because those are globally
additive, so another crate supporting Date would cause it to be enabled,
which the first crate might not be able to deal with.

Since that library does not conflict with itself, what one could do is 
incompatible semver bump (0.9.x -> 0.10.x or so), since Cargo does allow
two incompatible versions to coexist, and links accordingly. However,
this could still cause trouble if sfv types got re-exported further,
allowing types from different versions to come into contact with each
other.


I guess the library was written with an assumption that new SF types
would never appear...



-Ilari

Received on Monday, 23 January 2023 16:17:36 UTC