On 24 Apr 2016, at 23:40, Chris Lattner via swift-evolution
<[email protected]> wrote:
> Int could then implement support for “x” to print hexadecimal, we could
> support left/right whitespace padding, and custom types could provide their
> own custom formatters (e.g. a string could have a title case formatter, or a
> "look up localized form of” modifier). We could then provide a “printf” that
> would allow traditional “%x0” substitutions.
I'm not quite sure why we'd want to support printf-style syntax in the first
place? Interpolation is more readable, as the formats contain their descriptive
variable names, and you don't have to worry about matching up format string
placeholder order and types with those of what you're actually passing. I.e.
string interpolation is to printf what type inference is to explicit
declarations, and what labeled parameters are to old-style C initializer lists.
So I'd say Swift should come at this from the other direction and ensure that
anything you were able to do with printf is also possible with interpolation
(if that means specifying some sort of format flag in-line as well, I could
live with that).
I do see the utility in allowing any custom type to be printed out via
interpolation though, and to allow them to at the least query the existing
flags as well. But should we really use single-character flags? C++, apart from
overloading bitshift, has the right idea:
cout << "foo" << hex << 123 << "\n";
is much more readable than
printf( "foo%x\n", 123 );
Maybe we could just use a function as the flag?
print( "foo\(hex(123))\n" )
would then expand into "foo" hex(123) "\n", where hex would just be an object
or function that takes an Int and returns a hex-formatted string? Though this'd
pollute the namespace I suppose. 123.hex() maybe? Then it could be an arbitrary
method on Int, added with a category.
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://orangejuiceliberationfront.com
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
