> On May 21, 2016, at 2:14 AM, Dave Abrahams via swift-evolution > <[email protected]> wrote: > > >> on Fri May 20 2016, Kevin Ballard <[email protected]> wrote: >> >>> On Tue, May 17, 2016, at 08:32 PM, Chris Lattner via swift-evolution wrote: >>> * What is your evaluation of the proposal? >> >> I'm a little nervous about this change, because converting things to >> strings is a fairly basic operation and it should be immediately >> obvious how to do that. That said, the described issues are pretty >> bad, and I know I've had to carefully triple-check sometimes to make >> sure I was calling the right initializer. So I'm +1 on the idea. >> >> That said, I don't like the name String(printing:). As others have >> pointed out, it sounds like this is related to print(), but this >> initializer does not actually print anything, it just converts any >> value into a string. I also don't like String(describing:) because >> it's too long. This initializer should be easier to call than >> String(reflecting:). Also, in my experience this initializer is >> particularly useful with code of the form `someOpt.map(String.init)`, >> and saying `someOpt.map(String.init(describing:))` is annoyingly long. >> >> Given this, I'd like to suggest the simpler `String(from:)`. It's >> short and generic, and it makes sense as it creates a String from any >> value. > > Not too bad. I could live with it. > >> I'm also not a fan of Dave's suggestion of removing this initializer >> entirely in favor of "\(foo)". This feels weird, and it also can't be >> turned into a first-class function value. > > { "\($0)" } > > ?
Yeah... Perl is back.. Mr Swift o' please, can we have some syntax sugering for this? Please, o' please :) > >> I also think that this approach may encourage people to start using >> the .description property instead, even though accessing this property >> is discouraged. >> >>> * Is the problem being addressed significant enough to warrant a change >>> to Swift? >> >> Yes. >> >>> * Does this proposal fit well with the feel and direction of Swift? >> >> Yes. Initializers that take one unlabeled argument are typically used >> for full-width conversions, and I don't think this initializer >> qualifies as a full-width conversion. >> >>> * If you have used other languages or libraries with a similar >>> feature, how do you feel that this proposal compares to those? >> >> Some languages have a global function that does this, such as Python's >> str(foo) or Haskell's `show`. Some languages have a method/property, >> such as Obj-C (-description) and Ruby (foo.to_s(), though I believe >> you can also say String(foo)). I'm not aware of any languages that >> require string interpolation for this functionality. Keeping the >> initializer and just giving it a label is similar to a global function >> or to Ruby's String(foo). Removing the initializer in favor of just >> just string interpolation does not compare to any language I know of. >> >>> * How much effort did you put into your review? A glance, a quick >>> reading, or an in-depth study? >> >> A quick reading of the proposal, and a reading of the review thread to date. >> >> -Kevin Ballard >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > -- > -Dave > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
