Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use DataProvider without AnyProvider in tutorial example #3948

Merged
merged 4 commits into from
Sep 5, 2023

Conversation

sffc
Copy link
Member

@sffc sffc commented Aug 27, 2023

Do we like this better or worse?

This is one of the main use cases for AnyProvider. If we're okay with users making this type of blanket impl and saying that _unstable constructors are safe with blanket impls, then it's a step toward phasing out AnyProvider.

See #3947

@sffc sffc requested a review from a team as a code owner August 27, 2023 00:47
@@ -269,31 +269,41 @@ use tinystr::tinystr;

pub struct CustomDecimalSymbolsProvider<P>(P);

impl<P> AnyProvider for CustomDecimalSymbolsProvider<P>
fn transform(any_res: AnyResponse) -> Result<AnyResponse, DataError> {
let mut dec_res: DataResponse<DecimalSymbolsV1Marker> = any_res.downcast()?;
Copy link
Member Author

@sffc sffc Aug 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that for some reason when I had this function inlined below, I got the following compile error:

error[E0271]: type mismatch resolving `<DecimalSymbolsV1Marker as DataMarker>::Yokeable == <M as DataMarker>::Yokeable`
  --> src/lib.rs:301:77
   |
37 |             let mut dec_res: DataResponse<DecimalSymbolsV1Marker> = any_res.downcast()?;
   |                                                                             ^^^^^^^^ expected `DecimalSymbolsV1<'_>`, found associated type
   |
   = note:       expected struct `DecimalSymbolsV1<'static>`
           found associated type `<M as DataMarker>::Yokeable`
   = help: consider constraining the associated type `<M as DataMarker>::Yokeable` to `DecimalSymbolsV1<'static>`
   = note: for more information, visit https://doc.rust-lang.org/book/ch19-03-advanced-traits.html

The whole point of going through AnyResponse is to work around that exact type of compile problem since we don't have specialization.

Moving the code into a helper function fixes the error. Compiler bug?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pushed a fix. You need to be explicit about what you're downcasting to.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, still seems like a bug that let foo: Foo<Bar> = foo()? would resolve differently than let foo = foo::<Bar>() with the signature fn foo<T>() -> Result<Foo<T>>

@@ -269,31 +269,41 @@ use tinystr::tinystr;

pub struct CustomDecimalSymbolsProvider<P>(P);

impl<P> AnyProvider for CustomDecimalSymbolsProvider<P>
fn transform(any_res: AnyResponse) -> Result<AnyResponse, DataError> {
let mut dec_res: DataResponse<DecimalSymbolsV1Marker> = any_res.downcast()?;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pushed a fix. You need to be explicit about what you're downcasting to.

let mut res = self.0.load(req)?;
if M::KEY == DecimalSymbolsV1Marker::KEY && req.locale.region() == Some(region!("CH")) {
// Cast from `DataPayload<M>` to `DataPayload<DecimalSymbolsV1Marker>`
let mut dec_res = res.wrap_into_any_response().downcast::<DecimalSymbolsV1Marker>()?;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should add a try_cast to DataPayload that does this fallible casting through Any.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, something along those lines. Maybe something that returns a &mut. But still, it's handy that we can do this with existing 1.2 API!

Comment on lines 276 to 277
M::Yokeable: icu_provider::MaybeSendSync + zerofrom::ZeroFrom<'static, M::Yokeable>,
for<'a> yoke::trait_hack::YokeTraitHack<<M::Yokeable as yoke::Yokeable<'a>>::Output>: Clone,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It'd be nice if these bounds where on KeyedDataMarker::Yokeable. We require them to be Send, Sync, ZeroFrom and Clone implicitly anyway, and they all are, so we shouldn't need to repeat this.

robertbastian
robertbastian previously approved these changes Aug 28, 2023
@sffc
Copy link
Member Author

sffc commented Aug 28, 2023

There's a better way to do this that we've been missing. #3952

// Cast from `DataPayload<M>` to `DataPayload<DecimalSymbolsV1Marker>`
let mut any_payload = generic_payload as &mut dyn Any;
if let Some(mut decimal_payload) = any_payload.downcast_mut::<DataPayload<DecimalSymbolsV1Marker>>() {
if req.locale.region() == Some(region!("CH")) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

put the CH check at the top level?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather keep the region nearer the payload override for readability. I don't have reason to believe that there's a performance difference between checking the TypeId of the payload versus the region; maybe there's a small difference but this code needs to exist either way.

@sffc sffc merged commit a2c4abe into unicode-org:main Sep 5, 2023
@sffc sffc deleted the dp-only branch September 5, 2023 19:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants