Oops remove the duplicate "@" in my example. On Tue, Jul 5, 2016 at 7:27 AM Shawn Erickson <shaw...@gmail.com> wrote:
> 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 > <http://my.host.com/pictures/%5C(self.pictureId> : "") > On Tue, Jul 5, 2016 at 7:14 AM James Campbell via swift-evolution < > swift-evolution@swift.org> 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* >> >> *ja...@supmenow.com <ja...@supmenow.com>⎥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 < >> swift-evolution@swift.org> 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 < >>> 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://twitter.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 >>> >>> >> _______________________________________________ >> 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
