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

[Shawn Erickson]

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 <
swift-evolution at 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*
>
> *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
>>
>>
> _______________________________________________
> 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/6b38955a/attachment.html>