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.
+1, personally I have taken to using `x+"str"+y` instead of
`"\(x)str\(y)"`, if x/y are strings, so I can get a compile-time error if I
do this accidentally.
But I do see the appeal of being able to print("the data: \(data)") for
simple use cases. Didn't someone earlier propose some modifiers/labels like
"\(describing: x)" ?
···
On Wed, May 18, 2016 at 11:50 AM, 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.
I'm getting used to go back to code and unwrap my optionals but if
this could be done more automatically in interpolation it'd be great.
···
On 18 May 2016 at 15: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.
+1 from me as well. All these “Optional(foo)” things showing up in user-facing strings are a pain, and since they don’t show up until runtime, it’s really easy to miss them.
Charles
···
On May 18, 2016, at 1:50 PM, 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.
Optional(foo) better depicts the actual type (it's an options string, after
all). If you're not happy with it, just use the nil coalescing operator
such as "\(foo ?? "")". This is from the same series of proposals as
implicit casting - there are reasons it's done the way it is.
···
On Wed, May 18, 2016 at 3:49 PM Jacob Bandes-Storch via swift-evolution < swift-evolution@swift.org> wrote:
+1, personally I have taken to using `x+"str"+y` instead of
`"\(x)str\(y)"`, if x/y are strings, so I can get a compile-time error if I
do this accidentally.
But I do see the appeal of being able to print("the data: \(data)") for
simple use cases. Didn't someone earlier propose some modifiers/labels like
"\(describing: x)" ?
On Wed, May 18, 2016 at 11:50 AM, 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.
Maybe it should print something different: the value itself if it is not nil, and "nil" otherwise?
Or there may be an optional warning for this case.
Or maybe both. But not just deprecate the feature altogether. It will make people use the "!" instead in unsafe places (like "\(someOptional!)") - it's better not to crash and print something strange instead. Especially when in production.
-Michael
···
Am 18.05.2016 um 20:50 schrieb Krystof Vasa via swift-evolution <swift-evolution@swift.org>:
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.
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.
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.
We could make Optional conform to CustomStringConvertible:
var description: String {
switch self {
case .some(let x): return "\(x)"
case .none: return "\(Wrapped.self)?.none"
}
}
- Dave Sweeris
···
On May 18, 2016, at 15:56, Michael Peternell via swift-evolution <swift-evolution@swift.org> wrote:
Well, I wouldn't deprecate them.
Maybe it should print something different: the value itself if it is not nil, and "nil" otherwise?
Or there may be an optional warning for this case.
Or maybe both. But not just deprecate the feature altogether. It will make people use the "!" instead in unsafe places (like "\(someOptional!)") - it's better not to crash and print something strange instead. Especially when in production.
-Michael
Am 18.05.2016 um 20:50 schrieb Krystof Vasa via swift-evolution <swift-evolution@swift.org>:
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.
On Wed, May 18, 2016 at 6:33 PM David Sweeris via swift-evolution < swift-evolution@swift.org> wrote:
We could make Optional conform to CustomStringConvertible:
var description: String {
switch self {
case .some(let x): return "\(x)"
case .none: return "\(Wrapped.self)?.none"
}
}
- Dave Sweeris
> On May 18, 2016, at 15:56, Michael Peternell via swift-evolution < > swift-evolution@swift.org> wrote:
>
> Well, I wouldn't deprecate them.
>
> Maybe it should print something different: the value itself if it is not
nil, and "nil" otherwise?
>
> Or there may be an optional warning for this case.
>
> Or maybe both. But not just deprecate the feature altogether. It will
make people use the "!" instead in unsafe places (like "\(someOptional!)")
- it's better not to crash and print something strange instead. Especially
when in production.
>
> -Michael
>
>> Am 18.05.2016 um 20:50 schrieb Krystof Vasa via swift-evolution < > swift-evolution@swift.org>:
>>
>> 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
From what I understand of this thread, the argument here is that directly using an optional in a string interpolation is almost never what you really want to do (except mainly for debugging purposes) but you wouldn't see this mistake until much later at runtime.
And I feel like one of Swift goals is to enable us, imperfect human creatures, to detect as many problems or mistakes as possible long before runtime.
···
On 19 mai 2016, at 00:56, Dan Appel via swift-evolution <swift-evolution@swift.org> wrote:
-1.
Optional(foo) better depicts the actual type (it's an options string, after all). If you're not happy with it, just use the nil coalescing operator such as "\(foo ?? "")". This is from the same series of proposals as implicit casting - there are reasons it's done the way it is.
On Wed, May 18, 2016 at 3:49 PM Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org> wrote:
+1, personally I have taken to using `x+"str"+y` instead of `"\(x)str\(y)"`, if x/y are strings, so I can get a compile-time error if I do this accidentally.
But I do see the appeal of being able to print("the data: \(data)") for simple use cases. Didn't someone earlier propose some modifiers/labels like "\(describing: x)" ?
On Wed, May 18, 2016 at 11:50 AM, 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.
Instead of \(optional) having to do \(optional?. description ?? "") or
whatever fallback string you want is not that cumbersome and can prevent
Optional(Foo) sort of strings from appearing in user facing text, which I
have seen in several shipping app store apps already.
···
On Thu, May 19, 2016 at 9:07 AM 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
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.
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.
The latest version of the proposal (that's not going to happen) can be found here - string-interpolation.md · GitHub - and I've implemented it for my own use here:
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@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.
Making string interpolation reject just optional (at compile time) when it doesn’t reject any other type sounds tricky to express.
What if instead Optional just didn’t decorate the wrapped value, outputting either the inner value or “nil” in these cases?
The debugDescription could remain "Optional(data)" style.
-DW
···
On May 19, 2016, at 12:52 AM, Valentin via swift-evolution <swift-evolution@swift.org> wrote:
From what I understand of this thread, the argument here is that directly using an optional in a string interpolation is almost never what you really want to do (except mainly for debugging purposes) but you wouldn't see this mistake until much later at runtime.
And I feel like one of Swift goals is to enable us, imperfect human creatures, to detect as many problems or mistakes as possible long before runtime.
On 19 mai 2016, at 00:56, Dan Appel via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
-1.
Optional(foo) better depicts the actual type (it's an options string, after all). If you're not happy with it, just use the nil coalescing operator such as "\(foo ?? "")". This is from the same series of proposals as implicit casting - there are reasons it's done the way it is.
On Wed, May 18, 2016 at 3:49 PM Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
+1, personally I have taken to using `x+"str"+y` instead of `"\(x)str\(y)"`, if x/y are strings, so I can get a compile-time error if I do this accidentally.
But I do see the appeal of being able to print("the data: \(data)") for simple use cases. Didn't someone earlier propose some modifiers/labels like "\(describing: x)" ?
On Wed, May 18, 2016 at 11:50 AM, Krystof Vasa via swift-evolution <swift-evolution@swift.org <mailto: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.
You know what's worse than seeing "Optional(my string value)" in a label?
Seeing "nil". When the optional is there, it is made clear to the developer
that the string they are showing *can be nil*. However, if you hide that
from the users you are less likely to unwrap that optional and hence more
likely to show the user "nil". This behavior really goes against some of
the core ideas of Swift - you want your code to be expressive but not
abstract away potentially useful information.
···
On Thu, May 19, 2016 at 12:24 AM David Waite <david@alkaline-solutions.com> wrote:
Making string interpolation reject just optional (at compile time) when it
doesn’t reject any other type sounds tricky to express.
What if instead Optional just didn’t decorate the wrapped value,
outputting either the inner value or “nil” in these cases?
The debugDescription could remain "Optional(data)" style.
-DW
On May 19, 2016, at 12:52 AM, Valentin via swift-evolution < > swift-evolution@swift.org> wrote:
From what I understand of this thread, the argument here is that directly
using an optional in a string interpolation is almost never what you really
want to do (except mainly for debugging purposes) but you wouldn't see this
mistake until much later at runtime.
And I feel like one of Swift goals is to enable us, imperfect human
creatures, to detect as many problems or mistakes as possible long before
runtime.
On 19 mai 2016, at 00:56, Dan Appel via swift-evolution < > swift-evolution@swift.org> wrote:
-1.
Optional(foo) better depicts the actual type (it's an options string,
after all). If you're not happy with it, just use the nil coalescing
operator such as "\(foo ?? "")". This is from the same series of proposals
as implicit casting - there are reasons it's done the way it is.
On Wed, May 18, 2016 at 3:49 PM Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote:
+1, personally I have taken to using `x+"str"+y` instead of
`"\(x)str\(y)"`, if x/y are strings, so I can get a compile-time error if I
do this accidentally.
But I do see the appeal of being able to print("the data: \(data)") for
simple use cases. Didn't someone earlier propose some modifiers/labels like
"\(describing: x)" ?
On Wed, May 18, 2016 at 11:50 AM, 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.
Actually, I just noticed the comment about never wanting to show an
optional value. That is a fair point, and worthy of consideration. I'm
happy as long as there is no surprising behavior going on :)
···
On Thu, May 19, 2016 at 12:28 AM Dan Appel <dan.appel00@gmail.com> wrote:
You know what's worse than seeing "Optional(my string value)" in a label?
Seeing "nil". When the optional is there, it is made clear to the developer
that the string they are showing *can be nil*. However, if you hide that
from the users you are less likely to unwrap that optional and hence more
likely to show the user "nil". This behavior really goes against some of
the core ideas of Swift - you want your code to be expressive but not
abstract away potentially useful information.
On Thu, May 19, 2016 at 12:24 AM David Waite <david@alkaline-solutions.com> > wrote:
Making string interpolation reject just optional (at compile time) when
it doesn’t reject any other type sounds tricky to express.
What if instead Optional just didn’t decorate the wrapped value,
outputting either the inner value or “nil” in these cases?
The debugDescription could remain "Optional(data)" style.
-DW
On May 19, 2016, at 12:52 AM, Valentin via swift-evolution < >> swift-evolution@swift.org> wrote:
From what I understand of this thread, the argument here is that directly
using an optional in a string interpolation is almost never what you really
want to do (except mainly for debugging purposes) but you wouldn't see this
mistake until much later at runtime.
And I feel like one of Swift goals is to enable us, imperfect human
creatures, to detect as many problems or mistakes as possible long before
runtime.
On 19 mai 2016, at 00:56, Dan Appel via swift-evolution < >> swift-evolution@swift.org> wrote:
-1.
Optional(foo) better depicts the actual type (it's an options string,
after all). If you're not happy with it, just use the nil coalescing
operator such as "\(foo ?? "")". This is from the same series of proposals
as implicit casting - there are reasons it's done the way it is.
On Wed, May 18, 2016 at 3:49 PM Jacob Bandes-Storch via swift-evolution < >> swift-evolution@swift.org> wrote:
+1, personally I have taken to using `x+"str"+y` instead of
`"\(x)str\(y)"`, if x/y are strings, so I can get a compile-time error if I
do this accidentally.
But I do see the appeal of being able to print("the data: \(data)") for
simple use cases. Didn't someone earlier propose some modifiers/labels like
"\(describing: x)" ?
On Wed, May 18, 2016 at 11:50 AM, 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.
Which is not something you figure out until runtime, wondering why the URL is nil. This is very annoying when you run into this issue repeatedly on several occasions because you forget to unwrap the value.
*This* is IMHO an undesired and unexpected behavior.
If interpolating optionals did become a warning, you'd immediately know about a potential bug: you don't check if path != nil.
BTW if you still want the original behavior of printing
which invokes debugDescription on the Optional, not the String (since there is no "?"), and you get the original value anyway. And this could be the Fix-It for it as well to maintain original behavior.
Krystof
···
On May 19, 2016, at 9:28 AM, Dan Appel <dan.appel00@gmail.com> wrote:
You know what's worse than seeing "Optional(my string value)" in a label? Seeing "nil". When the optional is there, it is made clear to the developer that the string they are showing can be nil. However, if you hide that from the users you are less likely to unwrap that optional and hence more likely to show the user "nil". This behavior really goes against some of the core ideas of Swift - you want your code to be expressive but not abstract away potentially useful information.
On Thu, May 19, 2016 at 12:24 AM David Waite <david@alkaline-solutions.com <mailto:david@alkaline-solutions.com>> wrote:
Making string interpolation reject just optional (at compile time) when it doesn’t reject any other type sounds tricky to express.
What if instead Optional just didn’t decorate the wrapped value, outputting either the inner value or “nil” in these cases?
The debugDescription could remain "Optional(data)" style.
-DW
On May 19, 2016, at 12:52 AM, Valentin via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
From what I understand of this thread, the argument here is that directly using an optional in a string interpolation is almost never what you really want to do (except mainly for debugging purposes) but you wouldn't see this mistake until much later at runtime.
And I feel like one of Swift goals is to enable us, imperfect human creatures, to detect as many problems or mistakes as possible long before runtime.
On 19 mai 2016, at 00:56, Dan Appel via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
-1.
Optional(foo) better depicts the actual type (it's an options string, after all). If you're not happy with it, just use the nil coalescing operator such as "\(foo ?? "")". This is from the same series of proposals as implicit casting - there are reasons it's done the way it is.
On Wed, May 18, 2016 at 3:49 PM Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
+1, personally I have taken to using `x+"str"+y` instead of `"\(x)str\(y)"`, if x/y are strings, so I can get a compile-time error if I do this accidentally.
But I do see the appeal of being able to print("the data: \(data)") for simple use cases. Didn't someone earlier propose some modifiers/labels like "\(describing: x)" ?
On Wed, May 18, 2016 at 11:50 AM, Krystof Vasa via swift-evolution <swift-evolution@swift.org <mailto: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.
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.