I've been bit by this many times. A warning would really have helped me.
> On 20 May 2016, at 07:06, Krystof Vasa via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Sorry, my previous example didn't use the string interpolation, it should be
>
> print("http://apple.com\(myURL.path)").
>
>> On May 20, 2016, at 7:04 AM, Dan Appel <dan.appe...@gmail.com> wrote:
>>
>> Thats a fair solution. I still disagree, but not as strongly.
>>
>> On Thu, May 19, 2016 at 10:01 PM Krystof Vasa <kv...@icloud.com> wrote:
>>> With this proposal in place:
>>>
>>> 1) The user would type print(myURL.path).
>>> 2) The compiler will immediately issue a warning about printing an optional
>>> - the user would hence learn about optionals *before* the code is run.
>>> 3) If he ran the code anyway, he'd still get Optional(/iphone/) anyway.
>>> 4) Xcode would offer a Fix-It, adding .debugDescription to the optional,
>>> getting Optional(/iphone/) on the anyway, yet again.
>>>
>>> I'm not saying *removing* the current behavior, but adding a warning for
>>> this - you'd get the same result ignoring the warning and applying the
>>> Fix-It, but you'd have control over this.
>>>
>>>> On May 20, 2016, at 6:48 AM, Dan Appel via swift-evolution
>>>> <swift-evolution@swift.org> wrote:
>>>>
>>>> >google for swift print optional stackoverflow. I think that kind of
>>>> >speaks for itself.
>>>>
>>>> I think this is actually an example of why the current behavior is a good
>>>> thing. I did just google that and the top comment of the first result
>>>> explains what an optional is. That is very good and encourages beginners
>>>> to understand how optionals work under the hood. If you hide that from
>>>> them, they will only be even more confused when they see just the string
>>>> "nil" pop up when it previously was showing the correct value.
>>>>
>>>>> On Thu, May 19, 2016 at 9:36 PM Krystof Vasa via swift-evolution
>>>>> <swift-evolution@swift.org> wrote:
>>>>> BTW - google for swift print optional stackoverflow. I think that kind of
>>>>> speaks for itself.
>>>>>
>>>>> > On May 19, 2016, at 6:07 PM, Jeremy Pereira via swift-evolution
>>>>> > <swift-evolution@swift.org> wrote:
>>>>> >
>>>>> > -1
>>>>> >
>>>>> > This seems to me like crippling string interpolation just because
>>>>> > sometimes we make mistakes. 99% of the time, if I interpolate an
>>>>> > optional, it’s because I want it that way. I don’t want to have to put
>>>>> > up with a warning or write the same boilerplate 99% of the time just to
>>>>> > flag up the 1% more easily. Sorry.
>>>>> >
>>>>> >> On 18 May 2016, at 19:50, Krystof Vasa 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
>>>>> >>
>>>>> >> _______________________________________________
>>>>> >> 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
>>>>
>>>> --
>>>> Dan Appel
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> --
>> Dan Appel
>
> _______________________________________________
> 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
