Shane F. Carr

It's still extremely unclear to me what the status is of datetime formatting options. I am confused because in registry.md, the language "The following options and their values are required...

Ok so it's not noncontroversial I'm reasonably convinced by the counter-arguments on points 1. On point 4, I'm mainly concerned when it is used for passing these things as unnamed...

On the point 7: we have generally been conservative with adding impls to our types, and I think it has served us well. We have a very large API surface,...

> I can provide the motivation for the clippy lint: Default impls enable a whole bunch of convenient functions like mem::take and stuff. It's annoying when you're working with a...

> This ... seems like exactly what we want to happen? They now are forced to consider where their data should come from. That's good. That should exactly be a...

> We could add a "enabled by feature foo" tag on the impl if we really want to improve this experience. The problem with docs on trait impls is that...

I think the fundamental disagreement is: we agree as a TC that offering developers a way to switch data sources is fundamental, but we don't agree on the degree to...

Based on the above, I could agree to this policy: 1. By default, we don't add `Default` impls that rely on compiled data, because doing so causes compiled data to...

Some discussion: - @zbraniecki I'm not sure I have a strong opinion on this, but in my experience, when modifying data, people want to either add locales or modify specific...

Here's another point. A Default impl could be one of two things: with-default-data or without-data. We have a small number of classes, such as LocaleFallbacker, that work in both modes....