What would be a better alternative is the ability to have a String Format Token that would unwrap a value, like so
let string = String(format: "http://%?/";, url) None is unwrapped to "http:///"; Some is unwrapped to "http://myurl.com/"; I think this would be a good trade off rather than having to do an awkward guard dance, make your code unsafe with force-unwraps or end-up with "Optional()" in your string. *___________________________________* *James⎥Head of Trolls* *[email protected] <[email protected]>⎥supmenow.com <http://supmenow.com>* *Sup* *Runway East * *10 Finsbury Square* *London* * EC2A 1AF * On 4 July 2016 at 16:41, Krystof Vasa via swift-evolution < [email protected]> wrote: > This is now being tracked as 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). > > The latest version of the proposal (that's not going to happen) can be > found here - > 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 > > 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 < > [email protected]> 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://twitter.com/davbeck > http://facebook.com/davbeck > > _______________________________________________ > 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 > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
