Re: signatures vs sf-date

[Lucas Pardue <[e-mail]>]

Hey,

On Mon, Jan 23, 2023 at 10:05 AM Julian Reschke <[e-mail]>
wrote:

> On 23.01.2023 07:56, Mark Nottingham wrote:
> >
> >
> >> On 19 Dec 2022, at 9:28 pm, Julian Reschke <[e-mail]>
> 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?
>

I use the Rust sfv crate, which at the time of writing doesn't support
sf-date. Generally for Item parsing, I pass it a character iterator, and it
returns a Rust enum with associated data that I pattern match on. Some
examples are in the test cases [1]. Say I have a field that is expected to
be a Boolean, I'd call parse_bare_item(<input>) and if the result is not Ok(
BareItem::Boolean(<actual value>)), then something is wrong and there's
various things I could do (log it, ignore it, reject it, etc).

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.

Cheers,
Lucas

[1] - https://github.com/undef1nd/sfv/blob/master/src/test_parser.rs#L324