[swift-evolution] [Review] SE-0089: Renaming String.init<T>(_: T)

Dave Abrahams dabrahams at apple.com
Fri May 20 19:14:38 CDT 2016


on Fri May 20 2016, Kevin Ballard <swift-evolution at swift.org> 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)" }

?

> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
-Dave



More information about the swift-evolution mailing list