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

[L. Mihalkovic]

> On May 21, 2016, at 2:14 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> 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)" }
> 
> ?

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