Make InvariantDataProvider support AnyProvider

[sffc]

We should make the InvariantDataProvider support AnyProvider. The InvariantDataProvider is the one that returns Default impls for data structs.

Currently, Default returns a sized type and therefore requires that we box it in an Rc when putting it into an AnyProvider. We should be able to instead make InvariantDataProvider support the CrabBake-like style of AnyProvider, which is a static reference.

This would likely involve a trait that data structs implement which returns a &'static T. I propose that we use ConstDefault for this purpose. I tested and it works for our use case, assuming that we make all our objects const-constructible, which CrabBake requires anyway.

Needs approval from:

• @Manishearth for Rust wisdom

[Manishearth]

Bit wary about the dependency, but this is a good idea. We can also use this as further impetus to zero-copy all of our types (note that non-zc types cannot ConstDefault)

[Manishearth]

I think @iainireland had some concerns about CrabBake and stuff requiring all of our types to be zerocopy, which inhibits experimentation. I guess to solve that here we need to make it so that ConstDefaultProvider also only supports zero-copy structs?

[sffc]

Yeah, trait bounds take care of the experimentation use case. If you try to construct a ConstDefaultProvider with a data struct that doesn't implement the trait, your code won't compile.

[iainireland]

My concern is about the learning curve of having a variety of different requirements, so overlapping requirements between this and crabbake are a good thing. It looks like we want zero-copy for many reasons, so I think we're priced in for that (and we're getting good value for the effort).

Are there any other likely obstacles to making all our objects const-constructible, beyond zero-copy?

[Manishearth]

Another slight concern is feature explosion. I think we need to merge up features and be careful about what we add. Or perhaps merge up the feature groups that we test.

[sffc]

Instead of using ConstDefault and adding that dependency, I think we should just introduce a trait in the data provider core crate like

trait UndData {
    const UND_DATA: Self;
}

And then we can rename "InvariantDataProvider" / "ConstDefaultProvider" to "UndProvider".

That trait should be implemented on data structs. If it is not implemented, then you won't be able to make a "UndProvider" for that particular data struct.

It is likely that Default impls will mostly look like this, which is fine:

impl Default for FooV1 {
    fn default() -> Self {
        Self::UND_DATA.clone()  // or zero-copy clone
    }
}

[Manishearth]

This works for me and I think that's nicer: we will have a particular notion of "default" and it's not necessary that the "default" for a type used in, say, DecimalSymbolsV1 is the same as one in DateTimeSymbolsV1

[sffc]

• @robertbastian - We'd be baking in data that could change across releases
• @zbraniecki - It's last-resort fallback data. I think that's OK.
• @sffc - What do we do about segmenter and properties data?
• @robertbastian - You fall back to some databake data
• @sffc - For properties, there's an issue about the struct having only one default impl, but multiple keys could point to it
• @sffc - There are 2 use cases: bootstrapping, and last resort fallback
• @robertbastian - The last resort fallback just results in incorrect behavior, especially if the structs don't contain the correct data, like for properties

Conclusion: Don't build a data provider around Default impls. Data structs can implement Default on a case-by-case basis and use AnyPayloadProvider to inject them.

[sffc]

Action: Document this decision, and also make sure AnyPayloadProvider is understandable and discoverable.