[swift-evolution] Proposal: Deprecate optionals in string interpolation

[James Campbell]

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*

*james at supmenow.com <james at 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 at 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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160705/963d0c31/attachment.html>