This is now being tracked as https://bugs.swift.org/browse/SR-1882 <https://bugs.swift.org/browse/SR-1882> - Chris (Lattner) thought this should not go through the official proposal process as something more complicated, but just add a warning with redundant parentheses around it silencing the warning (http://article.gmane.org/gmane.comp.lang.swift.evolution/20960 <http://article.gmane.org/gmane.comp.lang.swift.evolution/20960>).
The latest version of the proposal (that's not going to happen) can be found here - https://gist.github.com/charlieMonroe/82e1519dd2b57029f69bc7abe99d7385 <https://gist.github.com/charlieMonroe/82e1519dd2b57029f69bc7abe99d7385> - and I've implemented it for my own use here: https://github.com/charlieMonroe/XUCore/blob/master/XUCore/additions/OptionalAdditions.swift <https://github.com/charlieMonroe/XUCore/blob/master/XUCore/additions/OptionalAdditions.swift> I find it better readable than using ?? or extra parentheses around the Optional... > On Jul 4, 2016, at 5:31 PM, David Beck via swift-evolution > <swift-evolution@swift.org> wrote: > > > The string interpolation is one of the strong sides of Swift, but also one > > of its weaknesses. > > > > It has happened to me more than once that I've used the interpolation with > > an optional by mistake and the result is then far from the expected result. > > > > This happened mostly before Swift 2.0's guard expression, but has happened > > since as well. > > > > The user will seldomly want to really get the output "Optional(something)", > > but is almost always expecting just "something". I believe this should be > > addressed by a warning to force the user to check the expression to prevent > > unwanted results. If you indeed want the output of an optional, it's almost > > always better to use the ?? operator and supply a null value placeholder, > > e.g. "\(myOptional ?? "<<none>>")", or use myOptional.debugDescription - > > which is a valid expression that will always return a non-optional value to > > force the current behavior. > > > > Krystof > > > > > > > > I really hope a proposal that solves this problem gets through, but I’m not > sure blocking optionals specifically is the way to go. In particular there > are other types that don’t have a clean string representation. I think that > by default string interpolation (meaning String creation specifically) should > only accept ValuePreservingStringConvertible types and produce an error for > everything else. > > But, in addition, we need a way to quickly print out values for debugging. I > think a new string type (DebugString for example) would be useful for this. > print and similar functions could take that as an argument and any type could > be interpolated in it’s argument. Further, if you simply say `let a = > “\(something)”` and something isn’t ValuePreservingStringConvertible, the > type of a should then be DebugString. Converting to string should be strait > forward, but require a small step to make it obvious that you are using a > string that could have weird characters. > > David Beck > http://davidbeck.co <http://davidbeck.co/> > http://twitter.com/davbeck <http://twitter.com/davbeck> > http://facebook.com/davbeck <http://facebook.com/davbeck> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
