I'm wondering which scenario this is actually wanted behavior:
- strings that are for user interaction? Definitely not.
- logs? To be honest, the logs riddled with Optional(value) are pain to read.
Following example:
key1: Optional("Value")
key2: nil
vs
key1: Value
key2: nil
Which is more readable in the log?
I just don't see the benefit of the current behavior than perhaps in Xcode's
playground where it displays the value on the right and perhaps a few minor
cases - but definitely not 99% of the time.
This is IMHO not crippling interpolation, just asking for a non-nil values for
it to be interpoled with.
Krystof
> On May 19, 2016, at 6:07 PM, Jeremy Pereira via swift-evolution
> <[email protected]> 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
>> <[email protected]> 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
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
