DryDataProvider for baked providers

[robertbastian]

No description provided.

[sffc]

The only use case for DryDataProvider is supported locales, and supported locales are only queryable if #5195 lands, so I don't think this should land unless #5195 lands.

I'd be okay making it an option on BakedExporter, though.

[robertbastian]

The only use case for DryDataProvider is supported locales

That's a very absolute statement.

and supported locales are only queryable if #5195 lands

Well they're queryable like this.

I'd be okay making it an option on BakedExporter, though.

I don't want to the API surface of the baked providers to change depending on ICU4X_DATA_DIR.

[robertbastian]

BlobDataProvider and FsDataProvider also implement DryDataProvider even if the data is using maximal deduplication.

The implementation is also required to use forking providers between baked and a provider where dry_load is actually cheaper.

[sffc]

There's also the question about whether we want DryDataProvider to potentially use a different trie. I think you made an argument that such behavior, making dry_load and load return different locales, should be off the table.

[sffc]

At some point I also remember you saying that you didn't want people using provider::Baked directly, and instead using the macros exported by the data crates.

I hear you about consistency with the blanket impls we have on BlobProvider and FsDataProvider. I think the differences with baked provider are:

1. BakedProvider is not blanked impld. It is impld for specific markers
2. We have been discussing different impls for Baked DryDataProvider in the other PR that might be more efficient, and this PR locks us into one particular impl

Why not just export separate macros like impldry_foo_marker_v1!?

[sffc]

^

[robertbastian]

BakedProvider is not blanked impld. It is impld for specific markers

I did this as a concession to you because you worry about source code size. I'm very happy to impl for specific markers.

We have been discussing different impls for Baked DryDataProvider in the other PR that might be more efficient, and this PR locks us into one particular impl

I don't see how it locks us in. It's a correct implementation.

[sffc]

BakedProvider is not blanked impld. It is impld for specific markers

I did this as a concession to you because you worry about source code size. I'm very happy to impl for specific markers.

I worry about code size when we can reduce it without causing side-effects (option 3 in #5230 for instance)

We have been discussing different impls for Baked DryDataProvider in the other PR that might be more efficient, and this PR locks us into one particular impl

I don't see how it locks us in. It's a correct implementation.

It locks us out of having marker-specific impls that do different things such as having a base languages supplement trie. But, I think your position is that impls where dry_load and load return different locales (even if they return the same success status) is off the table?

[sffc]

My concerns haven't changed since my last review

Should we get more feedback from others or discuss in a WG call?

[robertbastian]

I unimplemented it for our concrete data providers, I hope this removes the point of contention.

[sffc]

This adds DryDataProvider impls for concrete markers in a way that users can opt-in via the macro call site. This is my preferred approach.

[sffc]

The code size impact seems smallish relative to the overall code size of these baked data files.