I would suggest something like the following (yeah I would URLComponents for this but this is just an example)... basically a short hand of some type for (a != nil ? a : b) to deal with optional in string construction.
"http://\(self.username + "@" : "default")@ my.host.com/pictures/\(self.pictureId : "") On Tue, Jul 5, 2016 at 7:14 AM James Campbell via swift-evolution < [email protected]> wrote: > 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
