Forget me if I'm wrong, but wouldn't localization requirements make string
interpolation unsuitable for user facing strings anyway?
(I remember localization being discussed previously, but don't recall it
turning into a proposal)
- David
Sent from my iPhone
> On 19 May 2016, at 19:06, Krystof Vasa via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> 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
>> <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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
