Open cpovirk opened 9 years ago
Interesting topic. I've seen issues with String.format
and the default locale several times in production code, most recently today. I think it's a problem worthy of Guava's help.
As you mentioned, this issue is seemingly on few people's radar. Raising awareness would be a good thing to do.
I would like this. Not as Strings.format
, though. Although different, when skimming over code this can easily get unnoticed.
I suppose there's some overlap with the recently added Strings.lenientFormat
, though that API is purportedly only for cases in which String.format
is unavailable or throwing an exception would obscure another exception.
(One thing that I'd overlooked is that there is (probably?) no problem if you use only %s
(via). That suggests that I overdid things a little back in cl/83859950 (e.g., in CacheBuilderSpec
). That's not really a problem, though.)
Fwiw, %s
is only safe if the corresponding argument is not Formattable
.
String.format
depends on the default locale, leading to problems like #1567. We can fix it by passingLocale.ROOT
to each call, but this is kind of ugly, especially for an API that exists in large part to eliminate ugly string-concatenation code.Where would it go?
Strings.format
: looks likeString.format
, possibly too much soStrings.rootLocaleFormat
: for easy static importRootLocale.format
: gives a place for future such methods. Are there any candidates?And how worried are we about use of the default locale here? Oddly, I'm not sure I've ever heard anyone crusading against
String.format
, even though there are crusaders against many other default-locale APIs. Maybe it's just less frequently noticed there, in part because users often just use%s
? Plus, the output is probably more often used for debugging than it would be for, e.g.,SimpleDateFormat
.