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

[Shawn Erickson]

Oops remove the duplicate "@" in my example.
On Tue, Jul 5, 2016 at 7:27 AM Shawn Erickson <shawnce at 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 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/76508109/attachment.html>