On Sat, Jun 4, 2016, at 11:24 AM, Chris Lattner via swift-evolution wrote:
> * What is your evaluation of the proposal?
+1 in general, but I still think String.init(describing:) is annoyingly long
and would prefer String.init(from:).
Also, I'm a little concerned by this bit:
> As a performance optimization, the implementation of the string literal
> interpolation syntax will be changed to prefer the unlabeled initializer when
> interpolating a type that is LosslessStringConvertible or that otherwise has
> an unlabeled String initializer, but use the String.init<T>(describing: T)
> initializer if not.
Right now string interpolation is done via the StringInterpolationConvertible
protocol, and in particular the implementation for String contains
public init<T>(stringInterpolationSegment expr: T) {
self = String(expr)
}
This implementation could be changed to test for LosslessStringConvertible, but
there's no way to test for "Does String have an unlabelled initializer that
accepts type T?", so the only way to implement this proposed optimization is by
adding extra compiler magic.
I'm also not convinced that this is a performance optimization at all. It seems
reasonable to expect that the unlabeled initializer would basically be sugar
for calling the labeled initializer (or accessing the description property
directly), which means there's no performance benefit to calling the unlabeled
initializer. I can't think of any good reason for a type to implement an
unlabeled String initializer that's more efficient than its implementation of
CustomStringConvertible or Streamable.
> * 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.
> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
A quick reading of the current proposal, and I participated in the original
review.
-Kevin Ballard
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
