Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Xiaodi Wu via swift-evolution]

On Tue, Oct 4, 2016 at 7:16 PM, Kevin Ballard  wrote:

> On Tue, Oct 4, 2016, at 12:01 PM, Xiaodi Wu wrote:
>
> On Tue, Oct 4, 2016 at 1:49 PM, Kevin Ballard  wrote:
>
>
> On Tue, Oct 4, 2016, at 11:34 AM, Xiaodi Wu wrote:
>
> On Tue, Oct 4, 2016 at 1:06 PM, Kevin Ballard via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> On Tue, Oct 4, 2016, at 10:44 AM, Mark Lacey wrote:
>
>
> On Oct 4, 2016, at 10:29 AM, Kevin Ballard via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Tue, Oct 4, 2016, at 10:28 AM, Nate Cook wrote:
>
> On Oct 3, 2016, at 5:49 PM, Kevin Ballard via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Mon, Oct 3, 2016, at 03:18 PM, Jordan Rose wrote:
>
>
> ...
>
>
> We had this at one point, but we took it out because people would forget
> to test the nil case. I think `?? ""` or `?? nil` really is the best answer
> here.
>
>
> But you can't write that, unless you're dealing specifically with an
> Optional.  If you try you'll get an error:
>
> unnamed.swift:2:19: error: binary operator '??' cannot be applied to
> operands of type 'Int?' and 'String'
> print("x: \(x ?? "nil")")
> ~ ^  ~
> unnamed.swift:2:19: note: overloads for '??' exist with these partially
> matching parameter lists: (T?, @autoclosure () throws -> T), (T?,
> @autoclosure () thro
> ws -> T?)
> print("x: \(x ?? "nil")")
>   ^
> This leads to writing code like "… \(x.map(String.init(describing:)) ??
> "nil")" which is pretty gross.
>
>
> I think that if we're going to add this warning we should make it possible
> to provide a string as an alternative. It seems like it should be possible
> to build a ?? operator with a (T?, String) ->
> _StringInterpolationSomething signature that works only in a string
> interpolation context.
>
> There are some types that aren't trivially constructible, or don't have
> clear alternatives for the nil case. Other times it might just not make
> sense to build a new instance simply to turn it into a string. If we're
> going to make people provide an alternative for optionals in this otherwise
> simple-to-use construct, let's make it simple to do so.
>
> This is undoubtedly a more complex approach that could be considered
> separately, but I think it would be a valuable part of how developers could
> transition their code.
>
>
> That’s definitely more complex, and seems like a completely orthogonal
> feature request.
>
>
> I like this idea. This combined with the warning for naively interpolating
> an Optional would be a good solution, because now when I see the warning I
> can trivially solve it with `?? "nil”`.
>
>
> If you can suppress the warning with `as T?` (where T? is the type of the
> thing being warned on), you wouldn’t need a form that specifically printed
> “nil”, correct?
>
>
>
> How many times do I need to repeat myself? I'm looking for a solution to
> the problem where printing Optionals sanely (e.g. no "Optional(…)" wrapper
> for .some values) is a PITA right now. Getting rid of the warning does not
> solve this problem. This is why I like Nate Cook's idea to enable `??
> "nil"` in string interpolations, because it *does* solve my problem. And
> with this tool, now the warning on printing Optionals becomes useful
> because it tells me where to add `?? "nil"`. Getting rid of the warning
> without the ability to add `?? "nil"` is not helpful to me, because I don't
> want to print "Optional(…)".
>
>
> I'm confused. Why not just add this to your project?
>
> ```
> extension Optional : CustomStringConvertible {
> public var description: String {
> guard let some = self else { return "nil" }
> return String(describing: some)
> }
> }
> ```
>
>
> Because that's globally changing the behavior of Optional in a way that's
> very surprising.
>
>
> Agreed, but I thought that's what you were asking for above?
>
>
> I wanted to change the behavior of string interpolation specifically, not
> the behavior of `String(describing: someOptionalValue)`.
>

It hadn't occurred to me that this was on the table. It would be very
surprising for string interpolation to behave differently from
`String.init(describing:)`, would it not?

-Kevin
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Kevin Ballard via swift-evolution]

On Tue, Oct 4, 2016, at 12:01 PM, Xiaodi Wu wrote:
> On Tue, Oct 4, 2016 at 1:49 PM, Kevin Ballard  wrote:
>> __
>> On Tue, Oct 4, 2016, at 11:34 AM, Xiaodi Wu wrote:
>>> On Tue, Oct 4, 2016 at 1:06 PM, Kevin Ballard via swift-evolution
>>>  wrote:
 __

 On Tue, Oct 4, 2016, at 10:44 AM, Mark Lacey wrote:
>
>> On Oct 4, 2016, at 10:29 AM, Kevin Ballard via swift-evolution
>>  wrote:
>>
>> On Tue, Oct 4, 2016, at 10:28 AM, Nate Cook wrote:
 On Oct 3, 2016, at 5:49 PM, Kevin Ballard via swift-evolution
  wrote:

 On Mon, Oct 3, 2016, at 03:18 PM, Jordan Rose wrote:
>>
>> ...
>>
> We had this at one point, but we took it out because people
> would forget to test the nil case. I think `?? ""` or `?? nil`
> really is the best answer here.

 But you can't write that, unless you're dealing specifically
 with an Optional.  If you try you'll get an error:

 unnamed.swift:2:19: error: binary operator '??' cannot be
 applied to operands of type 'Int?' and 'String'
 print("x: \(x ?? "nil")")
 ~ ^  ~
 unnamed.swift:2:19: note: overloads for '??' exist with these
 partially matching parameter lists: (T?, @autoclosure () throws
 -> T), (T?, @autoclosure () thro
 ws -> T?)
 print("x: \(x ?? "nil")")
   ^
 This leads to writing code like "…
 \(x.map(String.init(describing:)) ?? "nil")" which is pretty
 gross.
>>>
>>> I think that if we're going to add this warning we should make
>>> it possible to provide a string as an alternative. It seems like
>>> it should be possible to build a ?? operator with a (T?, String)
>>> -> _StringInterpolationSomething signature that works only in a
>>> string interpolation context.
>>>
>>> There are some types that aren't trivially constructible, or
>>> don't have clear alternatives for the nil case. Other times it
>>> might just not make sense to build a new instance simply to turn
>>> it into a string. If we're going to make people provide an
>>> alternative for optionals in this otherwise simple-to-use
>>> construct, let's make it simple to do so.
>>>
>>> This is undoubtedly a more complex approach that could be
>>> considered separately, but I think it would be a valuable part
>>> of how developers could transition their code.
>
> That’s definitely more complex, and seems like a completely
> orthogonal feature request.
>
>>>
>> I like this idea. This combined with the warning for naively
>> interpolating an Optional would be a good solution, because now
>> when I see the warning I can trivially solve it with `?? "nil”`.
>
> If you can suppress the warning with `as T?` (where T? is the type
> of the thing being warned on), you wouldn’t need a form that
> specifically printed “nil”, correct?


 How many times do I need to repeat myself? I'm looking for a
 solution to the problem where printing Optionals sanely (e.g. no
 "Optional(…)" wrapper for .some values) is a PITA right now.
 Getting rid of the warning does not solve this problem. This is why
 I like Nate Cook's idea to enable `?? "nil"` in string
 interpolations, because it *does* solve my problem. And with this
 tool, now the warning on printing Optionals becomes useful because
 it tells me where to add `?? "nil"`. Getting rid of the warning
 without the ability to add `?? "nil"` is not helpful to me, because
 I don't want to print "Optional(…)".
>>>
>>> I'm confused. Why not just add this to your project?
>>>
>>> ```
>>> extension Optional : CustomStringConvertible {
>>> public var description: String {
>>> guard let some = self else { return "nil" }
>>> return String(describing: some)
>>> }
>>> }
>>> ```
>>
>> Because that's globally changing the behavior of Optional in a way
>> that's very surprising.
>
> Agreed, but I thought that's what you were asking for above?

I wanted to change the behavior of string interpolation specifically,
not the behavior of `String(describing: someOptionalValue)`.

-Kevin
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Xiaodi Wu via swift-evolution]

On Tue, Oct 4, 2016 at 1:49 PM, Kevin Ballard  wrote:

> On Tue, Oct 4, 2016, at 11:34 AM, Xiaodi Wu wrote:
>
> On Tue, Oct 4, 2016 at 1:06 PM, Kevin Ballard via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> On Tue, Oct 4, 2016, at 10:44 AM, Mark Lacey wrote:
>
>
> On Oct 4, 2016, at 10:29 AM, Kevin Ballard via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Tue, Oct 4, 2016, at 10:28 AM, Nate Cook wrote:
>
> On Oct 3, 2016, at 5:49 PM, Kevin Ballard via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Mon, Oct 3, 2016, at 03:18 PM, Jordan Rose wrote:
>
>
> ...
>
>
> We had this at one point, but we took it out because people would forget
> to test the nil case. I think `?? ""` or `?? nil` really is the best answer
> here.
>
>
> But you can't write that, unless you're dealing specifically with an
> Optional.  If you try you'll get an error:
>
> unnamed.swift:2:19: error: binary operator '??' cannot be applied to
> operands of type 'Int?' and 'String'
> print("x: \(x ?? "nil")")
> ~ ^  ~
> unnamed.swift:2:19: note: overloads for '??' exist with these partially
> matching parameter lists: (T?, @autoclosure () throws -> T), (T?,
> @autoclosure () thro
> ws -> T?)
> print("x: \(x ?? "nil")")
>   ^
> This leads to writing code like "… \(x.map(String.init(describing:)) ??
> "nil")" which is pretty gross.
>
>
> I think that if we're going to add this warning we should make it possible
> to provide a string as an alternative. It seems like it should be possible
> to build a ?? operator with a (T?, String) ->
> _StringInterpolationSomething signature that works only in a string
> interpolation context.
>
> There are some types that aren't trivially constructible, or don't have
> clear alternatives for the nil case. Other times it might just not make
> sense to build a new instance simply to turn it into a string. If we're
> going to make people provide an alternative for optionals in this otherwise
> simple-to-use construct, let's make it simple to do so.
>
> This is undoubtedly a more complex approach that could be considered
> separately, but I think it would be a valuable part of how developers could
> transition their code.
>
>
> That’s definitely more complex, and seems like a completely orthogonal
> feature request.
>
>
> I like this idea. This combined with the warning for naively interpolating
> an Optional would be a good solution, because now when I see the warning I
> can trivially solve it with `?? "nil”`.
>
>
> If you can suppress the warning with `as T?` (where T? is the type of the
> thing being warned on), you wouldn’t need a form that specifically printed
> “nil”, correct?
>
>
>
> How many times do I need to repeat myself? I'm looking for a solution to
> the problem where printing Optionals sanely (e.g. no "Optional(…)" wrapper
> for .some values) is a PITA right now. Getting rid of the warning does not
> solve this problem. This is why I like Nate Cook's idea to enable `??
> "nil"` in string interpolations, because it *does* solve my problem. And
> with this tool, now the warning on printing Optionals becomes useful
> because it tells me where to add `?? "nil"`. Getting rid of the warning
> without the ability to add `?? "nil"` is not helpful to me, because I don't
> want to print "Optional(…)".
>
>
> I'm confused. Why not just add this to your project?
>
> ```
> extension Optional : CustomStringConvertible {
> public var description: String {
> guard let some = self else { return "nil" }
> return String(describing: some)
> }
> }
> ```
>
>
> Because that's globally changing the behavior of Optional in a way that's
> very surprising.
>

Agreed, but I thought that's what you were asking for above?


>
>
> -Kevin
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Kevin Ballard via swift-evolution]

On Tue, Oct 4, 2016, at 11:34 AM, Xiaodi Wu wrote:
> On Tue, Oct 4, 2016 at 1:06 PM, Kevin Ballard via swift-evolution  evolut...@swift.org> wrote:
>> __
>>
>> On Tue, Oct 4, 2016, at 10:44 AM, Mark Lacey wrote:
>>>
 On Oct 4, 2016, at 10:29 AM, Kevin Ballard via swift-evolution >>> evolut...@swift.org> wrote:

 On Tue, Oct 4, 2016, at 10:28 AM, Nate Cook wrote:
>> On Oct 3, 2016, at 5:49 PM, Kevin Ballard via swift-evolution > evolut...@swift.org> wrote:
>>
>> On Mon, Oct 3, 2016, at 03:18 PM, Jordan Rose wrote:

 ...

>>> We had this at one point, but we took it out because people
>>> would forget to test the nil case. I think `?? ""` or `?? nil`
>>> really is the best answer here.
>>
>> But you can't write that, unless you're dealing specifically with
>> an Optional.  If you try you'll get an error:
>>
>> unnamed.swift:2:19: error: binary operator '??' cannot be applied
>> to operands of type 'Int?' and 'String'
>> print("x: \(x ?? "nil")")
>> ~ ^  ~
>> unnamed.swift:2:19: note: overloads for '??' exist with these
>> partially matching parameter lists: (T?, @autoclosure () throws
>> -> T), (T?, @autoclosure () thro
>> ws -> T?)
>> print("x: \(x ?? "nil")")
>>   ^
>> This leads to writing code like "…
>> \(x.map(String.init(describing:)) ?? "nil")" which is pretty
>> gross.
>
> I think that if we're going to add this warning we should make it
> possible to provide a string as an alternative. It seems like it
> should be possible to build a ?? operator with a (T?, String) ->
> _StringInterpolationSomething signature that works only in a
> string interpolation context.
>
> There are some types that aren't trivially constructible, or don't
> have clear alternatives for the nil case. Other times it might
> just not make sense to build a new instance simply to turn it into
> a string. If we're going to make people provide an alternative for
> optionals in this otherwise simple-to-use construct, let's make it
> simple to do so.
>
> This is undoubtedly a more complex approach that could be
> considered separately, but I think it would be a valuable part of
> how developers could transition their code.
>>>
>>> That’s definitely more complex, and seems like a completely
>>> orthogonal feature request.
>>>
>
 I like this idea. This combined with the warning for naively
 interpolating an Optional would be a good solution, because now
 when I see the warning I can trivially solve it with `?? "nil”`.
>>>
>>> If you can suppress the warning with `as T?` (where T? is the type
>>> of the thing being warned on), you wouldn’t need a form that
>>> specifically printed “nil”, correct?
>>
>>
>> How many times do I need to repeat myself? I'm looking for a solution
>> to the problem where printing Optionals sanely (e.g. no "Optional(…)"
>> wrapper for .some values) is a PITA right now. Getting rid of the
>> warning does not solve this problem. This is why I like Nate Cook's
>> idea to enable `?? "nil"` in string interpolations, because it *does*
>> solve my problem. And with this tool, now the warning on printing
>> Optionals becomes useful because it tells me where to add `?? "nil"`.
>> Getting rid of the warning without the ability to add `?? "nil"` is
>> not helpful to me, because I don't want to print "Optional(…)".
>
> I'm confused. Why not just add this to your project?
>
> ```
> extension Optional : CustomStringConvertible {
> public var description: String {
> guard let some = self else { return "nil" }
> return String(describing: some)
> }
> }
> ```

Because that's globally changing the behavior of Optional in a way
that's very surprising.

-Kevin
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Xiaodi Wu via swift-evolution]

On Tue, Oct 4, 2016 at 1:06 PM, Kevin Ballard via swift-evolution <
swift-evolution@swift.org> wrote:

> On Tue, Oct 4, 2016, at 10:44 AM, Mark Lacey wrote:
>
>
> On Oct 4, 2016, at 10:29 AM, Kevin Ballard via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Tue, Oct 4, 2016, at 10:28 AM, Nate Cook wrote:
>
> On Oct 3, 2016, at 5:49 PM, Kevin Ballard via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Mon, Oct 3, 2016, at 03:18 PM, Jordan Rose wrote:
>
>
> ...
>
>
> We had this at one point, but we took it out because people would forget
> to test the nil case. I think `?? ""` or `?? nil` really is the best answer
> here.
>
>
> But you can't write that, unless you're dealing specifically with an
> Optional.  If you try you'll get an error:
>
> unnamed.swift:2:19: error: binary operator '??' cannot be applied to
> operands of type 'Int?' and 'String'
> print("x: \(x ?? "nil")")
> ~ ^  ~
> unnamed.swift:2:19: note: overloads for '??' exist with these partially
> matching parameter lists: (T?, @autoclosure () throws -> T), (T?,
> @autoclosure () thro
> ws -> T?)
> print("x: \(x ?? "nil")")
>   ^
> This leads to writing code like "… \(x.map(String.init(describing:)) ??
> "nil")" which is pretty gross.
>
>
> I think that if we're going to add this warning we should make it possible
> to provide a string as an alternative. It seems like it should be possible
> to build a ?? operator with a (T?, String) ->
> _StringInterpolationSomething signature that works only in a string
> interpolation context.
>
> There are some types that aren't trivially constructible, or don't have
> clear alternatives for the nil case. Other times it might just not make
> sense to build a new instance simply to turn it into a string. If we're
> going to make people provide an alternative for optionals in this otherwise
> simple-to-use construct, let's make it simple to do so.
>
> This is undoubtedly a more complex approach that could be considered
> separately, but I think it would be a valuable part of how developers could
> transition their code.
>
>
> That’s definitely more complex, and seems like a completely orthogonal
> feature request.
>
>
> I like this idea. This combined with the warning for naively interpolating
> an Optional would be a good solution, because now when I see the warning I
> can trivially solve it with `?? "nil”`.
>
>
> If you can suppress the warning with `as T?` (where T? is the type of the
> thing being warned on), you wouldn’t need a form that specifically printed
> “nil”, correct?
>
>
> How many times do I need to repeat myself? I'm looking for a solution to
> the problem where printing Optionals sanely (e.g. no "Optional(…)" wrapper
> for .some values) is a PITA right now. Getting rid of the warning does not
> solve this problem. This is why I like Nate Cook's idea to enable `??
> "nil"` in string interpolations, because it *does* solve my problem. And
> with this tool, now the warning on printing Optionals becomes useful
> because it tells me where to add `?? "nil"`. Getting rid of the warning
> without the ability to add `?? "nil"` is not helpful to me, because I don't
> want to print "Optional(…)".
>

I'm confused. Why not just add this to your project?

```
extension Optional : CustomStringConvertible {
public var description: String {
guard let some = self else { return "nil" }
return String(describing: some)
}
}
```


-Kevin Ballard
>
> ___
> 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

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Robert Widmann via swift-evolution]

It's an interesting idea that needs to be written down in a separate proposal 
and is tangentially related to the problem we are trying to solve here and now. 
 It is trivial to define this operator and was suggested by Charlie as new API 
to be added to Optional the last time improving Optionals in interpolation 
segments was discussed.  For now we're trying to keep it light and bugfix-esque.

~Robert Widmann

2016/10/04 13:29、Kevin Ballard via swift-evolution  
のメッセージ:

> On Tue, Oct 4, 2016, at 10:28 AM, Nate Cook wrote:
>>> On Oct 3, 2016, at 5:49 PM, Kevin Ballard via swift-evolution 
>>>  wrote:
>>> 
>>> On Mon, Oct 3, 2016, at 03:18 PM, Jordan Rose wrote:
> 
> ...
> 
 We had this at one point, but we took it out because people would forget 
 to test the nil case. I think `?? ""` or `?? nil` really is the best 
 answer here.
>>> 
>>> But you can't write that, unless you're dealing specifically with an 
>>> Optional.  If you try you'll get an error:
>>> 
>>> unnamed.swift:2:19: error: binary operator '??' cannot be applied to 
>>> operands of type 'Int?' and 'String'
>>> print("x: \(x ?? "nil")")
>>> ~ ^  ~
>>> unnamed.swift:2:19: note: overloads for '??' exist with these partially 
>>> matching parameter lists: (T?, @autoclosure () throws -> T), (T?, 
>>> @autoclosure () thro
>>> ws -> T?)
>>> print("x: \(x ?? "nil")")
>>>   ^
>>> This leads to writing code like "… \(x.map(String.init(describing:)) ?? 
>>> "nil")" which is pretty gross.
>> 
>> I think that if we're going to add this warning we should make it possible 
>> to provide a string as an alternative. It seems like it should be possible 
>> to build a ?? operator with a (T?, String) -> _StringInterpolationSomething 
>> signature that works only in a string interpolation context.
>> 
>> There are some types that aren't trivially constructible, or don't have 
>> clear alternatives for the nil case. Other times it might just not make 
>> sense to build a new instance simply to turn it into a string. If we're 
>> going to make people provide an alternative for optionals in this otherwise 
>> simple-to-use construct, let's make it simple to do so.
>> 
>> This is undoubtedly a more complex approach that could be considered 
>> separately, but I think it would be a valuable part of how developers could 
>> transition their code.
> 
> I like this idea. This combined with the warning for naively interpolating an 
> Optional would be a good solution, because now when I see the warning I can 
> trivially solve it with `?? "nil"`.
> 
> -Kevin Ballard
> 
> ___
> 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

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Joe Groff via swift-evolution]

> On Oct 4, 2016, at 11:06 AM, Kevin Ballard via swift-evolution 
>  wrote:
> 
> On Tue, Oct 4, 2016, at 10:44 AM, Mark Lacey wrote:
>> 
>>> On Oct 4, 2016, at 10:29 AM, Kevin Ballard via swift-evolution 
>>> > wrote:
>>> 
>>> On Tue, Oct 4, 2016, at 10:28 AM, Nate Cook wrote:
> On Oct 3, 2016, at 5:49 PM, Kevin Ballard via swift-evolution 
> > wrote:
> 
> On Mon, Oct 3, 2016, at 03:18 PM, Jordan Rose wrote:
>>> 
>>> ...
>>> 
>> We had this at one point, but we took it out because people would forget 
>> to test the nil case. I think `?? ""` or `?? nil` really is the best 
>> answer here.
> 
> But you can't write that, unless you're dealing specifically with an 
> Optional.  If you try you'll get an error:
> 
> unnamed.swift:2:19: error: binary operator '??' cannot be applied to 
> operands of type 'Int?' and 'String'
> print("x: \(x ?? "nil")")
> ~ ^  ~
> unnamed.swift:2:19: note: overloads for '??' exist with these partially 
> matching parameter lists: (T?, @autoclosure () throws -> T), (T?, 
> @autoclosure () thro
> ws -> T?)
> print("x: \(x ?? "nil")")
>   ^
> This leads to writing code like "… \(x.map(String.init(describing:)) ?? 
> "nil")" which is pretty gross.
 
 I think that if we're going to add this warning we should make it possible 
 to provide a string as an alternative. It seems like it should be possible 
 to build a ?? operator with a (T?, String) -> 
 _StringInterpolationSomething signature that works only in a string 
 interpolation context.
 
 There are some types that aren't trivially constructible, or don't have 
 clear alternatives for the nil case. Other times it might just not make 
 sense to build a new instance simply to turn it into a string. If we're 
 going to make people provide an alternative for optionals in this 
 otherwise simple-to-use construct, let's make it simple to do so.
 
 This is undoubtedly a more complex approach that could be considered 
 separately, but I think it would be a valuable part of how developers 
 could transition their code.
>> 
>> That’s definitely more complex, and seems like a completely orthogonal 
>> feature request.
>> 
 
>>> I like this idea. This combined with the warning for naively interpolating 
>>> an Optional would be a good solution, because now when I see the warning I 
>>> can trivially solve it with `?? "nil”`.
>> 
>> If you can suppress the warning with `as T?` (where T? is the type of the 
>> thing being warned on), you wouldn’t need a form that specifically printed 
>> “nil”, correct?
> 
> How many times do I need to repeat myself? I'm looking for a solution to the 
> problem where printing Optionals sanely (e.g. no "Optional(…)" wrapper for 
> .some values) is a PITA right now. Getting rid of the warning does not solve 
> this problem. This is why I like Nate Cook's idea to enable `?? "nil"` in 
> string interpolations, because it does solve my problem. And with this tool, 
> now the warning on printing Optionals becomes useful because it tells me 
> where to add `?? "nil"`. Getting rid of the warning without the ability to 
> add `?? "nil"` is not helpful to me, because I don't want to print 
> "Optional(…)".

A string interpolation segment can accept any type, so 'x ?? "nil"' arguably 
ought to be able to work by joining both sides of the ?? to 'Any', as if you'd 
written `(x as Any?) ?? ("nil" as Any)`. IIRC we have some artificial 
limitations on deducing `Any`, since it can obviously be problematic to have 
things like array literals automatically fall into [Any] because you 
accidentally mixed types, but string interpolations are loosely-typed by 
design. I wonder if there's anything we could do to admit it in this case.

-Joe

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Mark Lacey via swift-evolution]

> On Oct 4, 2016, at 10:29 AM, Kevin Ballard via swift-evolution 
>  wrote:
> 
> On Tue, Oct 4, 2016, at 10:28 AM, Nate Cook wrote:
>>> On Oct 3, 2016, at 5:49 PM, Kevin Ballard via swift-evolution 
>>> > wrote:
>>> 
>>> On Mon, Oct 3, 2016, at 03:18 PM, Jordan Rose wrote:
> 
> ...
> 
 We had this at one point, but we took it out because people would forget 
 to test the nil case. I think `?? ""` or `?? nil` really is the best 
 answer here.
>>> 
>>> But you can't write that, unless you're dealing specifically with an 
>>> Optional.  If you try you'll get an error:
>>> 
>>> unnamed.swift:2:19: error: binary operator '??' cannot be applied to 
>>> operands of type 'Int?' and 'String'
>>> print("x: \(x ?? "nil")")
>>> ~ ^  ~
>>> unnamed.swift:2:19: note: overloads for '??' exist with these partially 
>>> matching parameter lists: (T?, @autoclosure () throws -> T), (T?, 
>>> @autoclosure () thro
>>> ws -> T?)
>>> print("x: \(x ?? "nil")")
>>>   ^
>>> This leads to writing code like "… \(x.map(String.init(describing:)) ?? 
>>> "nil")" which is pretty gross.
>> 
>> I think that if we're going to add this warning we should make it possible 
>> to provide a string as an alternative. It seems like it should be possible 
>> to build a ?? operator with a (T?, String) -> _StringInterpolationSomething 
>> signature that works only in a string interpolation context.
>> 
>> There are some types that aren't trivially constructible, or don't have 
>> clear alternatives for the nil case. Other times it might just not make 
>> sense to build a new instance simply to turn it into a string. If we're 
>> going to make people provide an alternative for optionals in this otherwise 
>> simple-to-use construct, let's make it simple to do so.
>> 
>> This is undoubtedly a more complex approach that could be considered 
>> separately, but I think it would be a valuable part of how developers could 
>> transition their code.

That’s definitely more complex, and seems like a completely orthogonal feature 
request.

> I like this idea. This combined with the warning for naively interpolating an 
> Optional would be a good solution, because now when I see the warning I can 
> trivially solve it with `?? "nil”`.

If you can suppress the warning with `as T?` (where T? is the type of the thing 
being warned on), you wouldn’t need a form that specifically printed “nil”, 
correct?

Mark

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Kevin Ballard via swift-evolution]

On Tue, Oct 4, 2016, at 10:28 AM, Nate Cook wrote:
>> On Oct 3, 2016, at 5:49 PM, Kevin Ballard via swift-evolution > evolut...@swift.org> wrote:
>>
>> On Mon, Oct 3, 2016, at 03:18 PM, Jordan Rose wrote:

 ...

>>> We had this at one point, but we took it out because people would
>>> forget to test the nil case. I think `?? ""` or `?? nil` really is
>>> the best answer here.
>>
>> But you can't write that, unless you're dealing specifically with an
>> Optional.  If you try you'll get an error:
>>
>> unnamed.swift:2:19: error: binary operator '??' cannot be applied to
>> operands of type 'Int?' and 'String'
>> print("x: \(x ?? "nil")")
>> ~ ^  ~
>> unnamed.swift:2:19: note: overloads for '??' exist with these
>> partially matching parameter lists: (T?, @autoclosure () throws ->
>> T), (T?, @autoclosure () thro
>> ws -> T?)
>> print("x: \(x ?? "nil")")
>>   ^
>> This leads to writing code like "… \(x.map(String.init(describing:))
>> ?? "nil")" which is pretty gross.
>
> I think that if we're going to add this warning we should make it
> possible to provide a string as an alternative. It seems like it
> should be possible to build a ?? operator with a (T?, String) ->
> _StringInterpolationSomething signature that works only in a string
> interpolation context.
>
> There are some types that aren't trivially constructible, or don't
> have clear alternatives for the nil case. Other times it might just
> not make sense to build a new instance simply to turn it into a
> string. If we're going to make people provide an alternative for
> optionals in this otherwise simple-to-use construct, let's make it
> simple to do so.
>
> This is undoubtedly a more complex approach that could be considered
> separately, but I think it would be a valuable part of how developers
> could transition their code.

I like this idea. This combined with the warning for naively
interpolating an Optional would be a good solution, because now when I
see the warning I can trivially solve it with `?? "nil"`.

-Kevin Ballard
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Nate Cook via swift-evolution]

> On Oct 3, 2016, at 5:49 PM, Kevin Ballard via swift-evolution 
>  wrote:
> 
> On Mon, Oct 3, 2016, at 03:18 PM, Jordan Rose wrote:
>>> 
>>> ...
>>> 
>> We had this at one point, but we took it out because people would forget to 
>> test the nil case. I think `?? ""` or `?? nil` really is the best answer 
>> here.
> 
> But you can't write that, unless you're dealing specifically with an 
> Optional.  If you try you'll get an error:
> 
> unnamed.swift:2:19: error: binary operator '??' cannot be applied to operands 
> of type 'Int?' and 'String'
> print("x: \(x ?? "nil")")
> ~ ^  ~
> unnamed.swift:2:19: note: overloads for '??' exist with these partially 
> matching parameter lists: (T?, @autoclosure () throws -> T), (T?, 
> @autoclosure () thro
> ws -> T?)
> print("x: \(x ?? "nil")")
>   ^
> This leads to writing code like "… \(x.map(String.init(describing:)) ?? 
> "nil")" which is pretty gross.

I think that if we're going to add this warning we should make it possible to 
provide a string as an alternative. It seems like it should be possible to 
build a ?? operator with a (T?, String) -> _StringInterpolationSomething 
signature that works only in a string interpolation context.

There are some types that aren't trivially constructible, or don't have clear 
alternatives for the nil case. Other times it might just not make sense to 
build a new instance simply to turn it into a string. If we're going to make 
people provide an alternative for optionals in this otherwise simple-to-use 
construct, let's make it simple to do so.

This is undoubtedly a more complex approach that could be considered 
separately, but I think it would be a valuable part of how developers could 
transition their code.

Nate

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Harlan Haskins via swift-evolution]

I would say it's surprising if you don't expect the value to be optional. Swift 
is such that you can write very long programs without knowing yourself the 
static type of every variable. It just takes one Optional property of a 
non-optional struct passed into a string interpolation segment to cause this 
behavior, as Keith showed earlier with url.absoluteString. This is especially 
bad because APIs are being notated with optionality, like in the Swift 2.2 -> 
2.3 shift, that were previously implicitly unwrapped.

I think a warning is the best way to go here. A developer probably didn't 
intend to interpolate an optional (I've never personally wanted the behavior) 
and this lets them know.

- Harlan

> On Oct 4, 2016, at 8:31 AM, Jeremy Pereira  
> wrote:
> 
> 
>> On 3 Oct 2016, at 22:41, Kevin Ballard via swift-evolution 
>>  wrote:
>> 
>> On Mon, Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift-evolution wrote:
>>> Swift developers frequently use string interpolation as a convenient, 
>>> concise syntax for interweaving variable values with strings. The 
>>> interpolation machinery, however, has surprising behavior in one specific 
>>> case: Optional. If a user puts an optional value into a string 
>>> interpolation segment, it will insert either "Optional("value")" or "nil" 
>>> in the resulting string. Neither of these is particularly desirable, so we 
>>> propose a warning and fix-it to surface solutions to these potential 
>>> mistakes.
>>> 
>> 
>> Is there any way we could instead allow Optionals but just print them the 
>> way we print ImplicitlyUnwrappedOptionals? That's almost always how I want 
>> my Optionals to work when interpolating. To be specific, this means for 
>> .some(x) we just print x, and for .none we print "nil”.
> 
> On the other hand, when I interpolate an optional, I want it to be obvious 
> that it is an Optional. If I didn’t want Optional(foo) in the string, I would 
> unwrap it first. 
> 
> I also disagree with the proposal that the behaviour is surprising. What else 
> would you expect? 
> 
> Having said that, I have no objection to the proposed warning.
> 
> 
>> 
>> -Kevin
>> ___
>> 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

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Jeremy Pereira via swift-evolution]

> On 3 Oct 2016, at 22:41, Kevin Ballard via swift-evolution 
>  wrote:
> 
> On Mon, Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift-evolution wrote:
>> Swift developers frequently use string interpolation as a convenient, 
>> concise syntax for interweaving variable values with strings. The 
>> interpolation machinery, however, has surprising behavior in one specific 
>> case: Optional. If a user puts an optional value into a string 
>> interpolation segment, it will insert either "Optional("value")" or "nil" in 
>> the resulting string. Neither of these is particularly desirable, so we 
>> propose a warning and fix-it to surface solutions to these potential 
>> mistakes.
>> 
> 
> Is there any way we could instead allow Optionals but just print them the way 
> we print ImplicitlyUnwrappedOptionals? That's almost always how I want my 
> Optionals to work when interpolating. To be specific, this means for .some(x) 
> we just print x, and for .none we print "nil”.

On the other hand, when I interpolate an optional, I want it to be obvious that 
it is an Optional. If I didn’t want Optional(foo) in the string, I would unwrap 
it first. 

I also disagree with the proposal that the behaviour is surprising. What else 
would you expect? 

Having said that, I have no objection to the proposed warning.


> 
> -Kevin
> ___
> 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

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Charlie Monroe via swift-evolution]

> On Oct 4, 2016, at 3:57 AM, Robert Widmann via swift-evolution 
>  wrote:
> 
>> 
>> On Oct 3, 2016, at 9:54 PM, Kevin Ballard > > wrote:
>> 
>> On Mon, Oct 3, 2016, at 06:49 PM, Robert Widmann wrote:
>>> 
 On Oct 3, 2016, at 8:49 PM, Kevin Ballard via swift-evolution 
 > wrote:
 
 I assume you meant that as a reply to me?
 
 The problem is twofold:
 
 1. Printing the value without adornment, or "nil" for nil, is a very 
 common thing to want to do and we shouldn't have to write code like 
 `\(x.map(String.init(describing:)) ?? "nil")` to accomplish it.
>>> 
>>> My point is before you were unable to do this without the ‘uglyness’ 
>>> presented here anyway [you would have gotten “Optional(“value”)”], so I 
>>> don’t see the point of raising this concern.  If you want the old behavior, 
>>> just ask for it with an explicit cast or `.debugDescription`.
>> 
>> This proposal was done because the current behavior of Optionals in string 
>> interpolation isn't very useful for most people. You're proposing banning it 
>> outright (with an escape hatch to recover the current behavior). I'm saying 
>> that, since it isn't very useful for most people, instead of banning it we 
>> could make it useful.
> 
> Then Optional needs to have a stable and useful `.description`, but I don’t 
> think it’s appropriate to have users rely on the output of `debugDescription` 
> much less use it in interpolated strings as it is now.  That’s why we wrote 
> this proposal.  We are changing no behavior, your programs will still compile 
> under this proposal, they will still execute with the same semantics as 
> before, you will just get a warning that you cannot and should not depend on 
> the debug representation of a type that specifically has a case for “no value 
> here”.  If you want to silence that warning you’re gonna have to jump through 
> some hoops - hoops that we’ll show you with fixits.

There were these concerns:

- the documentation explicitly discourages people to call description or 
debugDescription from within the code. So my original suggestion to make the 
fixit simply call debugDescription was met with resistance since this is 
discouraged. I am not sure about the reasoning for this though.

- some people did find the Optional(value) wrap useful and changing it could be 
viewed on as breaking change, though cases where the user may be testing a 
string for Optional seems rare at best. But again, there were voices that were 
loudly against.

- suggestion by Chris Lattner was to silence the warning either by:
- wrapping the expression in extra parentheses
- adding ?? and default value

Personally, I do not like this suggestion since it makes the code readability 
low due to the fact that the expression is within a string and thus formatting 
options that would help you improve readability are limited. 

I've suggested adding two methods to Optional:

- func descriptionWithDefaultValue(_ value: String = "nil") which while more 
descriptive isn't discouraged from being called directly and allows you to 
specify nil value (I have use cases for empty string, etc.)

- var detailedDescription: String - simply returns current implementation of 
debugDescription


My extension of Optional:

https://github.com/charlieMonroe/XUCore/blob/master/XUCore/additions/OptionalAdditions.swift
 


Original proposal:

https://gist.github.com/charlieMonroe/82e1519dd2b57029f69bc7abe99d7385 



> 
>> -Kevin
>> 
 2. Due to the changes made to IUOs, if you use a IUO in a string 
 interpolation, previously it would print as desired (either the value or 
 the string `"nil"`) but now it prints as Optional (e.g. with the 
 `"Optional(…)"` wrapper).
>>> 
>>> IUOs are not in the scope for this proposal, but I get your point.
>>> 
 
 -Kevin
 
 On Mon, Oct 3, 2016, at 05:43 PM, Robert Widmann via swift-evolution wrote:
> Under our proposal you can return to the old semantics of printing nil 
> with an explicit optional cast - one which we will offer to insert for 
> you.
> 
> Otherwise if you actually intend for a default value that value would 
> have type Int, not String.  Under the current regime if you want to print 
> something custom the for nil the way you've got it now you're going to 
> have to go through the reflecting initializer anyway so I don't see a 
> problem here.
> 
> ~Robert Widmann
> 
> 2016/10/03 19:25、Charlie Monroe via swift-evolution 
> > のメッセージ:
>> I've already suggested this quite some time back and was told that this 
>> 

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Robert Widmann via swift-evolution]

Forgive me for mixing terminology from before stating “If you want the old 
behavior” and the like.  What I meant is “If you want to silence the warning”.  
I should point out that it is just that: a warning.  We specifically mention 
that we didn’t spring for a hard error because that would make this a 
source-breaking proposal and we realize that it is useful to be able to quickly 
print an optional to test something.  But at the end of the day you should 
think about the representation of data flowing through your program and be 
explicit about whether you want the debug interpretation of an optional value 
or whether you intended - as we believe is true of the majority of cases - to 
provide a default non-optional value.

> On Oct 3, 2016, at 9:54 PM, Kevin Ballard  wrote:
> 
> On Mon, Oct 3, 2016, at 06:49 PM, Robert Widmann wrote:
>> 
>>> On Oct 3, 2016, at 8:49 PM, Kevin Ballard via swift-evolution 
>>> > wrote:
>>> 
>>> I assume you meant that as a reply to me?
>>> 
>>> The problem is twofold:
>>> 
>>> 1. Printing the value without adornment, or "nil" for nil, is a very common 
>>> thing to want to do and we shouldn't have to write code like 
>>> `\(x.map(String.init(describing:)) ?? "nil")` to accomplish it.
>> 
>> My point is before you were unable to do this without the ‘uglyness’ 
>> presented here anyway [you would have gotten “Optional(“value”)”], so I 
>> don’t see the point of raising this concern.  If you want the old behavior, 
>> just ask for it with an explicit cast or `.debugDescription`.
> 
> This proposal was done because the current behavior of Optionals in string 
> interpolation isn't very useful for most people. You're proposing banning it 
> outright (with an escape hatch to recover the current behavior). I'm saying 
> that, since it isn't very useful for most people, instead of banning it we 
> could make it useful.
> 
> -Kevin
> 
>>> 2. Due to the changes made to IUOs, if you use a IUO in a string 
>>> interpolation, previously it would print as desired (either the value or 
>>> the string `"nil"`) but now it prints as Optional (e.g. with the 
>>> `"Optional(…)"` wrapper).
>> 
>> IUOs are not in the scope for this proposal, but I get your point.
>> 
>>> 
>>> -Kevin
>>> 
>>> On Mon, Oct 3, 2016, at 05:43 PM, Robert Widmann via swift-evolution wrote:
 Under our proposal you can return to the old semantics of printing nil 
 with an explicit optional cast - one which we will offer to insert for you.
 
 Otherwise if you actually intend for a default value that value would have 
 type Int, not String.  Under the current regime if you want to print 
 something custom the for nil the way you've got it now you're going to 
 have to go through the reflecting initializer anyway so I don't see a 
 problem here.
 
 ~Robert Widmann
 
 2016/10/03 19:25、Charlie Monroe via swift-evolution 
 > のメッセージ:
> I've already suggested this quite some time back and was told that this 
> doesn't need to go through evolution. It's filed here: 
> https://bugs.swift.org/browse/SR-1882 
> 
> 
> Unfortunately, I haven't had time to look into it myself and I'm unlikely 
> to have the time anytime soon...
> 
>> On Oct 3, 2016, at 7:52 PM, Harlan Haskins via swift-evolution 
>> > wrote:
>> 
>> 
>> Hey all,
>> 
>> Julio Carrettoni, Robert Widmann, and I have been working on a proposal 
>> to mitigate something that's burned us all since Swift 1. We'd love some 
>> feedback!
>> 
>> It's available here: 
>> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd 
>> 
>> 
>> I've posted the current draft below.
>> 
>> Thanks,
>> Harlan Haskins
>> 
>> Disallow Optionals in String Interpolation Segments
>> 
>> Proposal: SE- 
>> 
>> Authors: Harlan Haskins , Julio 
>> Carrettoni , Robert Widmann 
>> 
>> Review Manager: TBD
>> Status: Awaiting revie
>>  
>> Introduction
>> 
>> Swift developers frequently use string interpolation as a convenient, 
>> concise syntax for interweaving variable values with strings. The 
>> interpolation machinery, however, has surprising behavior in one 
>> specific case: Optional. If a user puts an optional value into a 
>> string interpolation segment, it will insert either "Optional("value")" 
>> or "nil" 

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Robert Widmann via swift-evolution]

> On Oct 3, 2016, at 9:54 PM, Kevin Ballard  wrote:
> 
> On Mon, Oct 3, 2016, at 06:49 PM, Robert Widmann wrote:
>> 
>>> On Oct 3, 2016, at 8:49 PM, Kevin Ballard via swift-evolution 
>>> > wrote:
>>> 
>>> I assume you meant that as a reply to me?
>>> 
>>> The problem is twofold:
>>> 
>>> 1. Printing the value without adornment, or "nil" for nil, is a very common 
>>> thing to want to do and we shouldn't have to write code like 
>>> `\(x.map(String.init(describing:)) ?? "nil")` to accomplish it.
>> 
>> My point is before you were unable to do this without the ‘uglyness’ 
>> presented here anyway [you would have gotten “Optional(“value”)”], so I 
>> don’t see the point of raising this concern.  If you want the old behavior, 
>> just ask for it with an explicit cast or `.debugDescription`.
> 
> This proposal was done because the current behavior of Optionals in string 
> interpolation isn't very useful for most people. You're proposing banning it 
> outright (with an escape hatch to recover the current behavior). I'm saying 
> that, since it isn't very useful for most people, instead of banning it we 
> could make it useful.

Then Optional needs to have a stable and useful `.description`, but I don’t 
think it’s appropriate to have users rely on the output of `debugDescription` 
much less use it in interpolated strings as it is now.  That’s why we wrote 
this proposal.  We are changing no behavior, your programs will still compile 
under this proposal, they will still execute with the same semantics as before, 
you will just get a warning that you cannot and should not depend on the debug 
representation of a type that specifically has a case for “no value here”.  If 
you want to silence that warning you’re gonna have to jump through some hoops - 
hoops that we’ll show you with fixits.

> -Kevin
> 
>>> 2. Due to the changes made to IUOs, if you use a IUO in a string 
>>> interpolation, previously it would print as desired (either the value or 
>>> the string `"nil"`) but now it prints as Optional (e.g. with the 
>>> `"Optional(…)"` wrapper).
>> 
>> IUOs are not in the scope for this proposal, but I get your point.
>> 
>>> 
>>> -Kevin
>>> 
>>> On Mon, Oct 3, 2016, at 05:43 PM, Robert Widmann via swift-evolution wrote:
 Under our proposal you can return to the old semantics of printing nil 
 with an explicit optional cast - one which we will offer to insert for you.
 
 Otherwise if you actually intend for a default value that value would have 
 type Int, not String.  Under the current regime if you want to print 
 something custom the for nil the way you've got it now you're going to 
 have to go through the reflecting initializer anyway so I don't see a 
 problem here.
 
 ~Robert Widmann
 
 2016/10/03 19:25、Charlie Monroe via swift-evolution 
 > のメッセージ:
> I've already suggested this quite some time back and was told that this 
> doesn't need to go through evolution. It's filed here: 
> https://bugs.swift.org/browse/SR-1882 
> 
> 
> Unfortunately, I haven't had time to look into it myself and I'm unlikely 
> to have the time anytime soon...
> 
>> On Oct 3, 2016, at 7:52 PM, Harlan Haskins via swift-evolution 
>> > wrote:
>> 
>> 
>> Hey all,
>> 
>> Julio Carrettoni, Robert Widmann, and I have been working on a proposal 
>> to mitigate something that's burned us all since Swift 1. We'd love some 
>> feedback!
>> 
>> It's available here: 
>> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd 
>> 
>> 
>> I've posted the current draft below.
>> 
>> Thanks,
>> Harlan Haskins
>> 
>> Disallow Optionals in String Interpolation Segments
>> 
>> Proposal: SE- 
>> 
>> Authors: Harlan Haskins , Julio 
>> Carrettoni , Robert Widmann 
>> 
>> Review Manager: TBD
>> Status: Awaiting revie
>>  
>> Introduction
>> 
>> Swift developers frequently use string interpolation as a convenient, 
>> concise syntax for interweaving variable values with strings. The 
>> interpolation machinery, however, has surprising behavior in one 
>> specific case: Optional. If a user puts an optional value into a 
>> string interpolation segment, it will insert either "Optional("value")" 
>> or "nil" in the resulting string. Neither of these is particularly 

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Kevin Ballard via swift-evolution]

On Mon, Oct 3, 2016, at 06:49 PM, Robert Widmann wrote:
>
>> On Oct 3, 2016, at 8:49 PM, Kevin Ballard via swift-evolution > evolut...@swift.org> wrote:
>>
>> I assume you meant that as a reply to me?
>>
>> The problem is twofold:
>>
>> 1. Printing the value without adornment, or "nil" for nil, is a
>>very common thing to want to do and we shouldn't have to write
>>code like `\(x.map(String.init(describing:)) ?? "nil")` to
>>accomplish it.
>
> My point is before you were unable to do this without the ‘uglyness’
> presented here anyway [you would have gotten “Optional(“value”)”], so
> I don’t see the point of raising this concern.  If you want the old
> behavior, just ask for it with an explicit cast or
> `.debugDescription`.

This proposal was done because the current behavior of Optionals in
string interpolation isn't very useful for most people. You're proposing
banning it outright (with an escape hatch to recover the current
behavior). I'm saying that, since it isn't very useful for most people,
instead of banning it we could make it useful.

-Kevin

>> 2. Due to the changes made to IUOs, if you use a IUO in a string
>>interpolation, previously it would print as desired (either the
>>value or the string `"nil"`) but now it prints as Optional (e.g.
>>with the `"Optional(…)"` wrapper).
>
> IUOs are not in the scope for this proposal, but I get your point.
>
>>
>> -Kevin
>>
>> On Mon, Oct 3, 2016, at 05:43 PM, Robert Widmann via swift-
>> evolution wrote:
>>> Under our proposal you can return to the old semantics of printing
>>> nil with an explicit optional cast - one which we will offer to
>>> insert for you.
>>>
>>> Otherwise if you actually intend for a default value that value
>>> would have type Int, not String.  Under the current regime if you
>>> want to print something custom the for nil the way you've got it now
>>> you're going to have to go through the reflecting initializer anyway
>>> so I don't see a problem here.
>>>
>>> ~Robert Widmann
>>>
>>> 2016/10/03 19:25、Charlie Monroe via swift-evolution >> evolut...@swift.org> のメッセージ:
 I've already suggested this quite some time back and was told that
 this doesn't need to go through evolution. It's filed here:
 https://bugs.swift.org/browse/SR-1882

 Unfortunately, I haven't had time to look into it myself and I'm
 unlikely to have the time anytime soon...

> On Oct 3, 2016, at 7:52 PM, Harlan Haskins via swift-evolution  evolut...@swift.org> wrote:
>
>
> Hey all,
>
> Julio Carrettoni, Robert Widmann, and I have been working on a
> proposal to mitigate something that's burned us all since Swift 1.
> We'd love some feedback!
>
> It's available here:
> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd
>
> I've posted the current draft below.
>
> Thanks,
> Harlan Haskins
>
> Disallow Optionals in String Interpolation Segments


>  * Proposal: SE-[1]
>  * Authors: Harlan Haskins[2], Julio Carrettoni[3], Robert
>Widmann[4]
>  * Review Manager: TBD
>  * Status: Awaiting revie
> Introduction
> Swift developers frequently use string interpolation as a
> convenient, concise syntax for interweaving variable values with
> strings. The interpolation machinery, however, has surprising
> behavior in one specific case: Optional. If a user puts an
> optional value into a string interpolation segment, it will insert
> either "Optional("value")" or "nil" in the resulting string.
> Neither of these is particularly desirable, so we propose a
> warning and fix-it to surface solutions to these potential
> mistakes.
> Swift-evolution thread: Discussion thread topic for that
> proposal[5]
> Motivation
> *The Swift Programming Language* defines string interpolation
> segments as "a way to construct a new String value from a mix of
> constants, variables, literals, and expressions". There is one
> type that runs counter to this definition: Optional. The .none
> case in particular is used to indicate the absence of a value.
> Moreover, its inclusion in interpolation segments leads to the
> dreaded "nil" in output that is often fed to UI elements. Even
> barring that, interpolating a non-nil optional value yields
> "Optional("value")", a result that is not useful even in logged
> output.
> Given that the Optional type is never fit for display to the end
> user, and can often be a surprising find in the console, we
> propose that requesting an Optional's debug description be an
> explicit act. This proposal now requires a warning when using an
> expression of Optional type within a string interpolation segment.
> Proposed solution
> The user will be warned after attempting to use an expression with
> type Optional in a string interpolation segment. They will then
> be offered 

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Robert Widmann via swift-evolution]

> On Oct 3, 2016, at 8:49 PM, Kevin Ballard via swift-evolution 
>  wrote:
> 
> I assume you meant that as a reply to me?
> 
> The problem is twofold:
> 
> 1. Printing the value without adornment, or "nil" for nil, is a very common 
> thing to want to do and we shouldn't have to write code like 
> `\(x.map(String.init(describing:)) ?? "nil")` to accomplish it.

My point is before you were unable to do this without the ‘uglyness’ presented 
here anyway [you would have gotten “Optional(“value”)”], so I don’t see the 
point of raising this concern.  If you want the old behavior, just ask for it 
with an explicit cast or `.debugDescription`.

> 2. Due to the changes made to IUOs, if you use a IUO in a string 
> interpolation, previously it would print as desired (either the value or the 
> string `"nil"`) but now it prints as Optional (e.g. with the `"Optional(…)"` 
> wrapper).

IUOs are not in the scope for this proposal, but I get your point.

> 
> -Kevin
> 
> On Mon, Oct 3, 2016, at 05:43 PM, Robert Widmann via swift-evolution wrote:
>> Under our proposal you can return to the old semantics of printing nil with 
>> an explicit optional cast - one which we will offer to insert for you.
>> 
>> Otherwise if you actually intend for a default value that value would have 
>> type Int, not String.  Under the current regime if you want to print 
>> something custom the for nil the way you've got it now you're going to have 
>> to go through the reflecting initializer anyway so I don't see a problem 
>> here.
>> 
>> ~Robert Widmann
>> 
>> 2016/10/03 19:25、Charlie Monroe via swift-evolution 
>> > のメッセージ:
>>> I've already suggested this quite some time back and was told that this 
>>> doesn't need to go through evolution. It's filed here: 
>>> https://bugs.swift.org/browse/SR-1882 
>>> 
>>> 
>>> Unfortunately, I haven't had time to look into it myself and I'm unlikely 
>>> to have the time anytime soon...
>>> 
 On Oct 3, 2016, at 7:52 PM, Harlan Haskins via swift-evolution 
 > wrote:
 
 
 Hey all,
 
 Julio Carrettoni, Robert Widmann, and I have been working on a proposal to 
 mitigate something that's burned us all since Swift 1. We'd love some 
 feedback!
 
 It's available here: 
 https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd 
 
 
 I've posted the current draft below.
 
 Thanks,
 Harlan Haskins
 
 Disallow Optionals in String Interpolation Segments
 
 Proposal: SE- 
 Authors: Harlan Haskins , Julio 
 Carrettoni , Robert Widmann 
 
 Review Manager: TBD
 Status: Awaiting revie
  
 Introduction
 
 Swift developers frequently use string interpolation as a convenient, 
 concise syntax for interweaving variable values with strings. The 
 interpolation machinery, however, has surprising behavior in one specific 
 case: Optional. If a user puts an optional value into a string 
 interpolation segment, it will insert either "Optional("value")" or "nil" 
 in the resulting string. Neither of these is particularly desirable, so we 
 propose a warning and fix-it to surface solutions to these potential 
 mistakes.
 
 Swift-evolution thread: Discussion thread topic for that proposal 
 
  
 Motivation
 
 The Swift Programming Language defines string interpolation segments as "a 
 way to construct a new String value from a mix of constants, variables, 
 literals, and expressions". There is one type that runs counter to this 
 definition: Optional. The .none case in particular is used to indicate the 
 absence of a value. Moreover, its inclusion in interpolation segments 
 leads to the dreaded "nil" in output that is often fed to UI elements. 
 Even barring that, interpolating a non-nil optional value yields 
 "Optional("value")", a result that is not useful even in logged output.
 
 Given that the Optional type is never fit for display to the end user, and 
 can often be a surprising find in the console, we propose that requesting 
 an Optional's debug description be an explicit act. This proposal now 
 requires a warning when using an expression of Optional type within a 
 string interpolation segment.
 
  
 

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Kevin Ballard via swift-evolution]

I assume you meant that as a reply to me?

The problem is twofold:

1. Printing the value without adornment, or "nil" for nil, is a very
   common thing to want to do and we shouldn't have to write code like
   `\(x.map(String.init(describing:)) ?? "nil")` to accomplish it.
2. Due to the changes made to IUOs, if you use a IUO in a string
   interpolation, previously it would print as desired (either the value
   or the string `"nil"`) but now it prints as Optional (e.g. with the
   `"Optional(…)"` wrapper).

-Kevin

On Mon, Oct 3, 2016, at 05:43 PM, Robert Widmann via swift-evolution wrote:
> Under our proposal you can return to the old semantics of printing
> nil with an explicit optional cast - one which we will offer to
> insert for you.
>
> Otherwise if you actually intend for a default value that value would
> have type Int, not String.  Under the current regime if you want to
> print something custom the for nil the way you've got it now you're
> going to have to go through the reflecting initializer anyway so I
> don't see a problem here.
>
> ~Robert Widmann
>
> 2016/10/03 19:25、Charlie Monroe via swift-evolution  evolut...@swift.org> のメッセージ:
>> I've already suggested this quite some time back and was told that
>> this doesn't need to go through evolution. It's filed here:
>> https://bugs.swift.org/browse/SR-1882
>>
>> Unfortunately, I haven't had time to look into it myself and I'm
>> unlikely to have the time anytime soon...
>>
>>> On Oct 3, 2016, at 7:52 PM, Harlan Haskins via swift-evolution >> evolut...@swift.org> wrote:
>>>
>>>
>>> Hey all,
>>>
>>> Julio Carrettoni, Robert Widmann, and I have been working on a
>>> proposal to mitigate something that's burned us all since Swift 1.
>>> We'd love some feedback!
>>>
>>> It's available here:
>>> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd
>>>
>>> I've posted the current draft below.
>>>
>>> Thanks,
>>> Harlan Haskins
>>>
>>> Disallow Optionals in String Interpolation Segments


>>>  * Proposal: SE-[1]
>>>  * Authors: Harlan Haskins[2], Julio Carrettoni[3], Robert
>>>Widmann[4]
>>>  * Review Manager: TBD
>>>  * Status: Awaiting revie
>>> Introduction
>>> Swift developers frequently use string interpolation as a
>>> convenient, concise syntax for interweaving variable values with
>>> strings. The interpolation machinery, however, has surprising
>>> behavior in one specific case: Optional. If a user puts an
>>> optional value into a string interpolation segment, it will insert
>>> either "Optional("value")" or "nil" in the resulting string. Neither
>>> of these is particularly desirable, so we propose a warning and fix-
>>> it to surface solutions to these potential mistakes.
>>> Swift-evolution thread: Discussion thread topic for that proposal[5]
>>> Motivation
>>> *The Swift Programming Language* defines string interpolation
>>> segments as "a way to construct a new String value from a mix of
>>> constants, variables, literals, and expressions". There is one type
>>> that runs counter to this definition: Optional. The .none case in
>>> particular is used to indicate the absence of a value. Moreover, its
>>> inclusion in interpolation segments leads to the dreaded "nil" in
>>> output that is often fed to UI elements. Even barring that,
>>> interpolating a non-nil optional value yields "Optional("value")", a
>>> result that is not useful even in logged output.
>>> Given that the Optional type is never fit for display to the end
>>> user, and can often be a surprising find in the console, we propose
>>> that requesting an Optional's debug description be an explicit act.
>>> This proposal now requires a warning when using an expression of
>>> Optional type within a string interpolation segment.
>>> Proposed solution
>>> The user will be warned after attempting to use an expression with
>>> type Optional in a string interpolation segment. They will then
>>> be offered a fixit suggesting they explicitly request the
>>> debugDescription of the Optional value instead.
>>> Detailed design
>>> Semantic analysis currently does not do much but guarantee the well-
>>> formedness of expressions in interpolation segments. These are then
>>> fed directly to String.init(stringInterpolationSegment:) and are run
>>> through the runtime reflection system to generate a description.
>>> Semantic analysis will be tweaked to inspect the result of solving
>>> an interpolation segment for an Optional and will offer a fixit in
>>> that case.
>>> Impact on existing code
>>> As this is a warning, code written before this proposal will
>>> continue to compile and run with the same semantics as before.
>>> Authors of code that makes use of this unsafe pattern will be
>>> offered a migration path to the safer, more explicit form.
>>> Alternatives considered


>>>  * A fixit that suggests a default value be inserted would be
>>>entirely appropriate (following the style of the fixit introduced
>>>in SE-0140[6]).


>>>  * Forbidding this 

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Robert Widmann via swift-evolution]

Under our proposal you can return to the old semantics of printing nil with an 
explicit optional cast - one which we will offer to insert for you.

Otherwise if you actually intend for a default value that value would have type 
Int, not String.  Under the current regime if you want to print something 
custom the for nil the way you've got it now you're going to have to go through 
the reflecting initializer anyway so I don't see a problem here.

~Robert Widmann

2016/10/03 19:25、Charlie Monroe via swift-evolution  
のメッセージ:

> I've already suggested this quite some time back and was told that this 
> doesn't need to go through evolution. It's filed here: 
> https://bugs.swift.org/browse/SR-1882
> 
> Unfortunately, I haven't had time to look into it myself and I'm unlikely to 
> have the time anytime soon...
> 
>> On Oct 3, 2016, at 7:52 PM, Harlan Haskins via swift-evolution 
>>  wrote:
>> 
>> Hey all,
>> 
>> Julio Carrettoni, Robert Widmann, and I have been working on a proposal to 
>> mitigate something that's burned us all since Swift 1. We'd love some 
>> feedback!
>> 
>> It's available here: 
>> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd
>> 
>> I've posted the current draft below.
>> 
>> Thanks,
>> Harlan Haskins
>> 
>> Disallow Optionals in String Interpolation Segments
>> Proposal: SE-
>> Authors: Harlan Haskins, Julio Carrettoni, Robert Widmann
>> Review Manager: TBD
>> Status: Awaiting revie
>> Introduction
>> 
>> Swift developers frequently use string interpolation as a convenient, 
>> concise syntax for interweaving variable values with strings. The 
>> interpolation machinery, however, has surprising behavior in one specific 
>> case: Optional. If a user puts an optional value into a string 
>> interpolation segment, it will insert either "Optional("value")" or "nil" in 
>> the resulting string. Neither of these is particularly desirable, so we 
>> propose a warning and fix-it to surface solutions to these potential 
>> mistakes.
>> 
>> Swift-evolution thread: Discussion thread topic for that proposal
>> 
>> Motivation
>> 
>> The Swift Programming Language defines string interpolation segments as "a 
>> way to construct a new String value from a mix of constants, variables, 
>> literals, and expressions". There is one type that runs counter to this 
>> definition: Optional. The .none case in particular is used to indicate the 
>> absence of a value. Moreover, its inclusion in interpolation segments leads 
>> to the dreaded "nil" in output that is often fed to UI elements. Even 
>> barring that, interpolating a non-nil optional value yields 
>> "Optional("value")", a result that is not useful even in logged output.
>> 
>> Given that the Optional type is never fit for display to the end user, and 
>> can often be a surprising find in the console, we propose that requesting an 
>> Optional's debug description be an explicit act. This proposal now requires 
>> a warning when using an expression of Optional type within a string 
>> interpolation segment.
>> 
>> Proposed solution
>> 
>> The user will be warned after attempting to use an expression with type 
>> Optional in a string interpolation segment. They will then be offered a 
>> fixit suggesting they explicitly request the debugDescription of the 
>> Optional value instead.
>> 
>> Detailed design
>> 
>> Semantic analysis currently does not do much but guarantee the 
>> well-formedness of expressions in interpolation segments. These are then fed 
>> directly to String.init(stringInterpolationSegment:) and are run through the 
>> runtime reflection system to generate a description. Semantic analysis will 
>> be tweaked to inspect the result of solving an interpolation segment for an 
>> Optional and will offer a fixit in that case.
>> 
>> Impact on existing code
>> 
>> As this is a warning, code written before this proposal will continue to 
>> compile and run with the same semantics as before. Authors of code that 
>> makes use of this unsafe pattern will be offered a migration path to the 
>> safer, more explicit form.
>> 
>> Alternatives considered
>> 
>> A fixit that suggests a default value be inserted would be entirely 
>> appropriate (following the style of the fixit introduced in SE-0140).
>> 
>> Forbidding this pattern by hard error would make this proposal a breaking 
>> change that is out of scope for this stage of Swift's development.
>> 
>> A fixit that introduces a force-unwrapping would technically work as well, 
>> however it would be fixing a dangerous operation with yet another dangerous 
>> operation.
>> 
>> 
>> 
>> Sent from my iPad
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> 

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Charlie Monroe via swift-evolution]

I've already suggested this quite some time back and was told that this doesn't 
need to go through evolution. It's filed here: 
https://bugs.swift.org/browse/SR-1882 

Unfortunately, I haven't had time to look into it myself and I'm unlikely to 
have the time anytime soon...

> On Oct 3, 2016, at 7:52 PM, Harlan Haskins via swift-evolution 
>  wrote:
> 
> Hey all,
> 
> Julio Carrettoni, Robert Widmann, and I have been working on a proposal to 
> mitigate something that's burned us all since Swift 1. We'd love some 
> feedback!
> 
> It's available here: 
> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd 
> 
> 
> I've posted the current draft below.
> 
> Thanks,
> Harlan Haskins
> 
> Disallow Optionals in String Interpolation Segments
> 
> Proposal: SE- 
> Authors: Harlan Haskins , Julio Carrettoni 
> , Robert Widmann 
> 
> Review Manager: TBD
> Status: Awaiting revie
>  
> Introduction
> 
> Swift developers frequently use string interpolation as a convenient, concise 
> syntax for interweaving variable values with strings. The interpolation 
> machinery, however, has surprising behavior in one specific case: 
> Optional. If a user puts an optional value into a string interpolation 
> segment, it will insert either "Optional("value")" or "nil" in the resulting 
> string. Neither of these is particularly desirable, so we propose a warning 
> and fix-it to surface solutions to these potential mistakes.
> 
> Swift-evolution thread: Discussion thread topic for that proposal 
> 
>  
> Motivation
> 
> The Swift Programming Language defines string interpolation segments as "a 
> way to construct a new String value from a mix of constants, variables, 
> literals, and expressions". There is one type that runs counter to this 
> definition: Optional. The .none case in particular is used to indicate the 
> absence of a value. Moreover, its inclusion in interpolation segments leads 
> to the dreaded "nil" in output that is often fed to UI elements. Even barring 
> that, interpolating a non-nil optional value yields "Optional("value")", a 
> result that is not useful even in logged output.
> 
> Given that the Optional type is never fit for display to the end user, and 
> can often be a surprising find in the console, we propose that requesting an 
> Optional's debug description be an explicit act. This proposal now requires a 
> warning when using an expression of Optional type within a string 
> interpolation segment.
> 
>  
> Proposed
>  solution
> 
> The user will be warned after attempting to use an expression with type 
> Optional in a string interpolation segment. They will then be offered a 
> fixit suggesting they explicitly request the debugDescription of the Optional 
> value instead.
> 
>  
> Detailed
>  design
> 
> Semantic analysis currently does not do much but guarantee the 
> well-formedness of expressions in interpolation segments. These are then fed 
> directly to String.init(stringInterpolationSegment:) and are run through the 
> runtime reflection system to generate a description. Semantic analysis will 
> be tweaked to inspect the result of solving an interpolation segment for an 
> Optional and will offer a fixit in that case.
> 
>  
> Impact
>  on existing code
> 
> As this is a warning, code written before this proposal will continue to 
> compile and run with the same semantics as before. Authors of code that makes 
> use of this unsafe pattern will be offered a migration path to the safer, 
> more explicit form.
> 
>  
> Alternatives
>  considered
> 
> A fixit that suggests a default value be inserted would be entirely 
> appropriate (following the style of the fixit introduced in SE-0140 
> ).
> 
> Forbidding this pattern by hard error would make this proposal a breaking 
> change that is out of scope for this stage of Swift's development.
> 
> A fixit that introduces a force-unwrapping would technically work as well, 
> however it would be fixing a dangerous operation with yet another dangerous 
> 

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Kevin Ballard via swift-evolution]

On Mon, Oct 3, 2016, at 03:18 PM, Jordan Rose wrote:
>
>> On Oct 3, 2016, at 14:41, Kevin Ballard via swift-evolution > evolut...@swift.org> wrote:
>>
>> On Mon, Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift-
>> evolution wrote:
>>> Swift developers frequently use string interpolation as a
>>> convenient, concise syntax for interweaving variable values with
>>> strings. The interpolation machinery, however, has surprising
>>> behavior in one specific case: Optional. If a user puts an
>>> optional value into a string interpolation segment, it will insert
>>> either "Optional("value")" or "nil" in the resulting string. Neither
>>> of these is particularly desirable, so we propose a warning and fix-
>>> it to surface solutions to these potential mistakes.
>>
>> Is there any way we could instead allow Optionals but just print
>> them the way we print ImplicitlyUnwrappedOptionals? That's almost
>> always how I want my Optionals to work when interpolating. To be
>> specific, this means for .some(x) we just print x, and for .none we
>> print "nil".
> We had this at one point, but we took it out because people would
> forget to test the nil case. I think `?? ""` or `?? nil` really is the
> best answer here.

But you can't write that, unless you're dealing specifically with an
Optional.  If you try you'll get an error:

unnamed.swift:2:19: error: binary operator '??' cannot be applied to
operands of type 'Int?' and 'String'
print("x: \(x ?? "nil")")
~ ^  ~
unnamed.swift:2:19: note: overloads for '??' exist with these partially
matching parameter lists: (T?, @autoclosure () throws -> T), (T?,
@autoclosure () thro
ws -> T?)
print("x: \(x ?? "nil")")
  ^
This leads to writing code like "… \(x.map(String.init(describing:)) ??
"nil")" which is pretty gross.

-Kevin
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Jordan Rose via swift-evolution]

> On Oct 3, 2016, at 14:41, Kevin Ballard via swift-evolution 
>  wrote:
> 
> On Mon, Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift-evolution wrote:
>> Swift developers frequently use string interpolation as a convenient, 
>> concise syntax for interweaving variable values with strings. The 
>> interpolation machinery, however, has surprising behavior in one specific 
>> case: Optional. If a user puts an optional value into a string 
>> interpolation segment, it will insert either "Optional("value")" or "nil" in 
>> the resulting string. Neither of these is particularly desirable, so we 
>> propose a warning and fix-it to surface solutions to these potential 
>> mistakes.
>> 
> 
> Is there any way we could instead allow Optionals but just print them the way 
> we print ImplicitlyUnwrappedOptionals? That's almost always how I want my 
> Optionals to work when interpolating. To be specific, this means for .some(x) 
> we just print x, and for .none we print "nil".

We had this at one point, but we took it out because people would forget to 
test the nil case. I think `?? ""` or `?? nil` really is the best answer here.

Jordan

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Kevin Ballard via swift-evolution]

On Mon, Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift-evolution wrote:
> Swift developers frequently use string interpolation as a convenient,
> concise syntax for interweaving variable values with strings. The
> interpolation machinery, however, has surprising behavior in one
> specific case: Optional. If a user puts an optional value into a
> string interpolation segment, it will insert either
> "Optional("value")" or "nil" in the resulting string. Neither of these
> is particularly desirable, so we propose a warning and fix-it to
> surface solutions to these potential mistakes.

Is there any way we could instead allow Optionals but just print them
the way we print ImplicitlyUnwrappedOptionals? That's almost always how
I want my Optionals to work when interpolating. To be specific, this
means for .some(x) we just print x, and for .none we print "nil".

-Kevin
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Mark Lacey via swift-evolution]

> On Oct 3, 2016, at 2:12 PM, Harlan Haskins  wrote:
> 
> If you don't think this needs a proposal

Well, that’s not up to me, so let’s wait until someone else chimes in. :)

Mark

> , then Robert has an implementation almost done. We could submit a PR later 
> today.
> 
> - Harlan
> 
> On Oct 3, 2016, at 4:06 PM, Mark Lacey via swift-evolution 
> > wrote:
> 
>> 
>>> On Oct 3, 2016, at 11:26 AM, Joe Groff via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On Oct 3, 2016, at 11:02 AM, Robert Widmann > wrote:
 
 Because the initializer here doesn’t take Any, it takes .
>>> 
>>> I think there's a case to be made to generalize the 'Any' warning to 
>>> Optional implicitly being deduced as a type variable binding in any 
>>> unconstrained context. What exactly constitutes 'implicit' and 
>>> 'unconstrained' is up for debate, though, and probably needs some 
>>> experimentation to figure out what feels good. For instance, explicitly 
>>> constructing an optional is a signal the optionality intentional. 
>>> Potentially, having multiple Optional parameters binding the same type 
>>> variable also increases the likelihood it's intended, for example:
>>> 
>>> func foo(x: T, y: T) {}
>>> 
>>> var x: Int? = 1
>>> var y: Int = 2
>>> foo(x, y) // One Optional isn't unwrapped, forcing the other to promote. 
>>> Maybe a mistake?
>>> var z: Int? = 3
>>> foo(x, z) // Two T parameters are Optional. Probably intentional?
>>> 
>>> Regardless of whether there's a more general principle we can base a 
>>> warning on, string interpolation and String(describing:) are common enough 
>>> pitfalls that they may just deserve special case treatment.
>> 
>> I think string interpolation could be handled pretty easily with a warning 
>> by extending the existing warning for Any. We just need to look at 
>> interpolation expressions and if any of the segments are optional-typed emit 
>> a warning unless they are explicitly casted to the optional type. The fixit 
>> can suggest explicit casting or using the debugDescription.
>> 
>> I’m not sure we really need an evolution proposal for that.
>> 
>> As for the more general topic of trickiness around optional injection into 
>> unconstrained generics: Yes, we should review that at some point as well. I 
>> recall seeing at least one concrete complaint about surprising behavior 
>> resulting from doing this in generic functions, but I cannot find the bug at 
>> the moment.
>> 
>> Mark
>> 
>> 
>>> 
>>> -Joe
>>> 
 ~Robert Widmann
 
> On Oct 3, 2016, at 2:00 PM, Harlan Haskins via swift-evolution 
> > wrote:
> 
> Unfortunately, Optional-to-Any does not currently hit this case because 
> IIRC it doesn't promote to Any in an interpolation segment. I tested this 
> with a ToT build yesterday.
> 
> - Harlan
> 
> On Oct 3, 2016, at 1:57 PM, Joe Groff  > wrote:
> 
>> We now emit a warning whenever an optional is used as an Any. I disagree 
>> that this should be an error, but it seems reasonable to warn (if we 
>> don't already thanks to the 'Any' warning).
>> 
>> -Joe
>> 
>>> On Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift-evolution 
>>> > wrote:
>>> 
>>> Hey all,
>>> 
>>> Julio Carrettoni, Robert Widmann, and I have been working on a proposal 
>>> to mitigate something that's burned us all since Swift 1. We'd love 
>>> some feedback!
>>> 
>>> It's available here: 
>>> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd 
>>> 
>>> 
>>> I've posted the current draft below.
>>> 
>>> Thanks,
>>> Harlan Haskins
>>> 
>>> Disallow Optionals in String Interpolation Segments
>>> 
>>> Proposal: SE- 
>>> 
>>> Authors: Harlan Haskins , Julio 
>>> Carrettoni , Robert Widmann 
>>> 
>>> Review Manager: TBD
>>> Status: Awaiting revie
>>>  
>>> Introduction
>>> 
>>> Swift developers frequently use string interpolation as a convenient, 
>>> concise syntax for interweaving variable values with strings. The 
>>> interpolation machinery, however, has surprising behavior in one 
>>> specific case: Optional. If a user puts an optional value into a 
>>> string interpolation segment, it will 

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Robert Widmann via swift-evolution]

Definitely right about that, the implementation 

 took all of 10 minutes after extending the OptionalToAnyCoercionWalker.  If 
you’ve got any comments, please let me know there.

~Robert Widmann

> On Oct 3, 2016, at 4:06 PM, Mark Lacey  wrote:
> 
>> 
>> On Oct 3, 2016, at 11:26 AM, Joe Groff via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Oct 3, 2016, at 11:02 AM, Robert Widmann  
>>> wrote:
>>> 
>>> Because the initializer here doesn’t take Any, it takes .
>> 
>> I think there's a case to be made to generalize the 'Any' warning to 
>> Optional implicitly being deduced as a type variable binding in any 
>> unconstrained context. What exactly constitutes 'implicit' and 
>> 'unconstrained' is up for debate, though, and probably needs some 
>> experimentation to figure out what feels good. For instance, explicitly 
>> constructing an optional is a signal the optionality intentional. 
>> Potentially, having multiple Optional parameters binding the same type 
>> variable also increases the likelihood it's intended, for example:
>> 
>> func foo(x: T, y: T) {}
>> 
>> var x: Int? = 1
>> var y: Int = 2
>> foo(x, y) // One Optional isn't unwrapped, forcing the other to promote. 
>> Maybe a mistake?
>> var z: Int? = 3
>> foo(x, z) // Two T parameters are Optional. Probably intentional?
>> 
>> Regardless of whether there's a more general principle we can base a warning 
>> on, string interpolation and String(describing:) are common enough pitfalls 
>> that they may just deserve special case treatment.
> 
> I think string interpolation could be handled pretty easily with a warning by 
> extending the existing warning for Any. We just need to look at interpolation 
> expressions and if any of the segments are optional-typed emit a warning 
> unless they are explicitly casted to the optional type. The fixit can suggest 
> explicit casting or using the debugDescription.
> 
> I’m not sure we really need an evolution proposal for that.
> 
> As for the more general topic of trickiness around optional injection into 
> unconstrained generics: Yes, we should review that at some point as well. I 
> recall seeing at least one concrete complaint about surprising behavior 
> resulting from doing this in generic functions, but I cannot find the bug at 
> the moment.
> 
> Mark
> 
> 
>> 
>> -Joe
>> 
>>> ~Robert Widmann
>>> 
 On Oct 3, 2016, at 2:00 PM, Harlan Haskins via swift-evolution 
  wrote:
 
 Unfortunately, Optional-to-Any does not currently hit this case because 
 IIRC it doesn't promote to Any in an interpolation segment. I tested this 
 with a ToT build yesterday.
 
 - Harlan
 
 On Oct 3, 2016, at 1:57 PM, Joe Groff  wrote:
 
> We now emit a warning whenever an optional is used as an Any. I disagree 
> that this should be an error, but it seems reasonable to warn (if we 
> don't already thanks to the 'Any' warning).
> 
> -Joe
> 
>> On Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift-evolution 
>>  wrote:
>> 
>> Hey all,
>> 
>> Julio Carrettoni, Robert Widmann, and I have been working on a proposal 
>> to mitigate something that's burned us all since Swift 1. We'd love some 
>> feedback!
>> 
>> It's available here: 
>> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd
>> 
>> I've posted the current draft below.
>> 
>> Thanks,
>> Harlan Haskins
>> 
>> Disallow Optionals in String Interpolation Segments
>> 
>>  • Proposal: SE-
>>  • Authors: Harlan Haskins, Julio Carrettoni, Robert Widmann
>>  • Review Manager: TBD
>>  • Status: Awaiting revie
>> Introduction
>> 
>> Swift developers frequently use string interpolation as a convenient, 
>> concise syntax for interweaving variable values with strings. The 
>> interpolation machinery, however, has surprising behavior in one 
>> specific case: Optional. If a user puts an optional value into a 
>> string interpolation segment, it will insert either "Optional("value")" 
>> or "nil" in the resulting string. Neither of these is particularly 
>> desirable, so we propose a warning and fix-it to surface solutions to 
>> these potential mistakes.
>> 
>> Swift-evolution thread: Discussion thread topic for that proposal
>> 
>> Motivation
>> 
>> The Swift Programming Language defines string interpolation segments as 
>> "a way to construct a new String value from a mix of constants, 
>> variables, literals, and expressions". There is one type that runs 
>> counter to this definition: Optional. The .none case in particular is 
>> used to indicate the absence of a 

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Harlan Haskins via swift-evolution]

If you don't think this needs a proposal, then Robert has an implementation 
almost done. We could submit a PR later today.

- Harlan

> On Oct 3, 2016, at 4:06 PM, Mark Lacey via swift-evolution 
>  wrote:
> 
> 
>>> On Oct 3, 2016, at 11:26 AM, Joe Groff via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> On Oct 3, 2016, at 11:02 AM, Robert Widmann  
>>> wrote:
>>> 
>>> Because the initializer here doesn’t take Any, it takes .
>> 
>> I think there's a case to be made to generalize the 'Any' warning to 
>> Optional implicitly being deduced as a type variable binding in any 
>> unconstrained context. What exactly constitutes 'implicit' and 
>> 'unconstrained' is up for debate, though, and probably needs some 
>> experimentation to figure out what feels good. For instance, explicitly 
>> constructing an optional is a signal the optionality intentional. 
>> Potentially, having multiple Optional parameters binding the same type 
>> variable also increases the likelihood it's intended, for example:
>> 
>> func foo(x: T, y: T) {}
>> 
>> var x: Int? = 1
>> var y: Int = 2
>> foo(x, y) // One Optional isn't unwrapped, forcing the other to promote. 
>> Maybe a mistake?
>> var z: Int? = 3
>> foo(x, z) // Two T parameters are Optional. Probably intentional?
>> 
>> Regardless of whether there's a more general principle we can base a warning 
>> on, string interpolation and String(describing:) are common enough pitfalls 
>> that they may just deserve special case treatment.
> 
> I think string interpolation could be handled pretty easily with a warning by 
> extending the existing warning for Any. We just need to look at interpolation 
> expressions and if any of the segments are optional-typed emit a warning 
> unless they are explicitly casted to the optional type. The fixit can suggest 
> explicit casting or using the debugDescription.
> 
> I’m not sure we really need an evolution proposal for that.
> 
> As for the more general topic of trickiness around optional injection into 
> unconstrained generics: Yes, we should review that at some point as well. I 
> recall seeing at least one concrete complaint about surprising behavior 
> resulting from doing this in generic functions, but I cannot find the bug at 
> the moment.
> 
> Mark
> 
> 
>> 
>> -Joe
>> 
>>> ~Robert Widmann
>>> 
 On Oct 3, 2016, at 2:00 PM, Harlan Haskins via swift-evolution 
  wrote:
 
 Unfortunately, Optional-to-Any does not currently hit this case because 
 IIRC it doesn't promote to Any in an interpolation segment. I tested this 
 with a ToT build yesterday.
 
 - Harlan
 
> On Oct 3, 2016, at 1:57 PM, Joe Groff  wrote:
> 
> We now emit a warning whenever an optional is used as an Any. I disagree 
> that this should be an error, but it seems reasonable to warn (if we 
> don't already thanks to the 'Any' warning).
> 
> -Joe
> 
>> On Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift-evolution 
>>  wrote:
>> 
>> Hey all,
>> 
>> Julio Carrettoni, Robert Widmann, and I have been working on a proposal 
>> to mitigate something that's burned us all since Swift 1. We'd love some 
>> feedback!
>> 
>> It's available here: 
>> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd
>> 
>> I've posted the current draft below.
>> 
>> Thanks,
>> Harlan Haskins
>> 
>> Disallow Optionals in String Interpolation Segments
>> 
>> Proposal: SE-
>> Authors: Harlan Haskins, Julio Carrettoni, Robert Widmann
>> Review Manager: TBD
>> Status: Awaiting revie
>> Introduction
>> 
>> Swift developers frequently use string interpolation as a convenient, 
>> concise syntax for interweaving variable values with strings. The 
>> interpolation machinery, however, has surprising behavior in one 
>> specific case: Optional. If a user puts an optional value into a 
>> string interpolation segment, it will insert either "Optional("value")" 
>> or "nil" in the resulting string. Neither of these is particularly 
>> desirable, so we propose a warning and fix-it to surface solutions to 
>> these potential mistakes.
>> 
>> Swift-evolution thread: Discussion thread topic for that proposal
>> 
>> Motivation
>> 
>> The Swift Programming Language defines string interpolation segments as 
>> "a way to construct a new String value from a mix of constants, 
>> variables, literals, and expressions". There is one type that runs 
>> counter to this definition: Optional. The .none case in particular is 
>> used to indicate the absence of a value. Moreover, its inclusion in 
>> interpolation segments leads to the dreaded "nil" in output that is 
>> often fed to UI elements. Even barring that, 

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Mark Lacey via swift-evolution]

> On Oct 3, 2016, at 11:26 AM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Oct 3, 2016, at 11:02 AM, Robert Widmann > > wrote:
>> 
>> Because the initializer here doesn’t take Any, it takes .
> 
> I think there's a case to be made to generalize the 'Any' warning to Optional 
> implicitly being deduced as a type variable binding in any unconstrained 
> context. What exactly constitutes 'implicit' and 'unconstrained' is up for 
> debate, though, and probably needs some experimentation to figure out what 
> feels good. For instance, explicitly constructing an optional is a signal the 
> optionality intentional. Potentially, having multiple Optional parameters 
> binding the same type variable also increases the likelihood it's intended, 
> for example:
> 
> func foo(x: T, y: T) {}
> 
> var x: Int? = 1
> var y: Int = 2
> foo(x, y) // One Optional isn't unwrapped, forcing the other to promote. 
> Maybe a mistake?
> var z: Int? = 3
> foo(x, z) // Two T parameters are Optional. Probably intentional?
> 
> Regardless of whether there's a more general principle we can base a warning 
> on, string interpolation and String(describing:) are common enough pitfalls 
> that they may just deserve special case treatment.

I think string interpolation could be handled pretty easily with a warning by 
extending the existing warning for Any. We just need to look at interpolation 
expressions and if any of the segments are optional-typed emit a warning unless 
they are explicitly casted to the optional type. The fixit can suggest explicit 
casting or using the debugDescription.

I’m not sure we really need an evolution proposal for that.

As for the more general topic of trickiness around optional injection into 
unconstrained generics: Yes, we should review that at some point as well. I 
recall seeing at least one concrete complaint about surprising behavior 
resulting from doing this in generic functions, but I cannot find the bug at 
the moment.

Mark


> 
> -Joe
> 
>> ~Robert Widmann
>> 
>>> On Oct 3, 2016, at 2:00 PM, Harlan Haskins via swift-evolution 
>>> > wrote:
>>> 
>>> Unfortunately, Optional-to-Any does not currently hit this case because 
>>> IIRC it doesn't promote to Any in an interpolation segment. I tested this 
>>> with a ToT build yesterday.
>>> 
>>> - Harlan
>>> 
>>> On Oct 3, 2016, at 1:57 PM, Joe Groff >> > wrote:
>>> 
 We now emit a warning whenever an optional is used as an Any. I disagree 
 that this should be an error, but it seems reasonable to warn (if we don't 
 already thanks to the 'Any' warning).
 
 -Joe
 
> On Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift-evolution 
> > wrote:
> 
> Hey all,
> 
> Julio Carrettoni, Robert Widmann, and I have been working on a proposal 
> to mitigate something that's burned us all since Swift 1. We'd love some 
> feedback!
> 
> It's available here: 
> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd 
> 
> 
> I've posted the current draft below.
> 
> Thanks,
> Harlan Haskins
> 
> Disallow Optionals in String Interpolation Segments
> 
> Proposal: SE- 
> Authors: Harlan Haskins , Julio 
> Carrettoni , Robert Widmann 
> 
> Review Manager: TBD
> Status: Awaiting revie
>  
> Introduction
> 
> Swift developers frequently use string interpolation as a convenient, 
> concise syntax for interweaving variable values with strings. The 
> interpolation machinery, however, has surprising behavior in one specific 
> case: Optional. If a user puts an optional value into a string 
> interpolation segment, it will insert either "Optional("value")" or "nil" 
> in the resulting string. Neither of these is particularly desirable, so 
> we propose a warning and fix-it to surface solutions to these potential 
> mistakes.
> 
> Swift-evolution thread: Discussion thread topic for that proposal 
> 
>  
> Motivation
> 
> The Swift Programming Language defines string interpolation segments as 
> "a way to construct a new String value from a mix of constants, 
> variables, literals, and expressions". There is one type that runs 
> counter to this definition: 

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Joe Groff via swift-evolution]

> On Oct 3, 2016, at 11:02 AM, Robert Widmann  wrote:
> 
> Because the initializer here doesn’t take Any, it takes .

I think there's a case to be made to generalize the 'Any' warning to Optional 
implicitly being deduced as a type variable binding in any unconstrained 
context. What exactly constitutes 'implicit' and 'unconstrained' is up for 
debate, though, and probably needs some experimentation to figure out what 
feels good. For instance, explicitly constructing an optional is a signal the 
optionality intentional. Potentially, having multiple Optional parameters 
binding the same type variable also increases the likelihood it's intended, for 
example:

func foo(x: T, y: T) {}

var x: Int? = 1
var y: Int = 2
foo(x, y) // One Optional isn't unwrapped, forcing the other to promote. Maybe 
a mistake?
var z: Int? = 3
foo(x, z) // Two T parameters are Optional. Probably intentional?

Regardless of whether there's a more general principle we can base a warning 
on, string interpolation and String(describing:) are common enough pitfalls 
that they may just deserve special case treatment.

-Joe

> ~Robert Widmann
> 
>> On Oct 3, 2016, at 2:00 PM, Harlan Haskins via swift-evolution 
>> > wrote:
>> 
>> Unfortunately, Optional-to-Any does not currently hit this case because IIRC 
>> it doesn't promote to Any in an interpolation segment. I tested this with a 
>> ToT build yesterday.
>> 
>> - Harlan
>> 
>> On Oct 3, 2016, at 1:57 PM, Joe Groff > > wrote:
>> 
>>> We now emit a warning whenever an optional is used as an Any. I disagree 
>>> that this should be an error, but it seems reasonable to warn (if we don't 
>>> already thanks to the 'Any' warning).
>>> 
>>> -Joe
>>> 
 On Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift-evolution 
 > wrote:
 
 Hey all,
 
 Julio Carrettoni, Robert Widmann, and I have been working on a proposal to 
 mitigate something that's burned us all since Swift 1. We'd love some 
 feedback!
 
 It's available here: 
 https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd 
 
 
 I've posted the current draft below.
 
 Thanks,
 Harlan Haskins
 
 Disallow Optionals in String Interpolation Segments
 
 Proposal: SE- 
 Authors: Harlan Haskins , Julio 
 Carrettoni , Robert Widmann 
 
 Review Manager: TBD
 Status: Awaiting revie
  
 Introduction
 
 Swift developers frequently use string interpolation as a convenient, 
 concise syntax for interweaving variable values with strings. The 
 interpolation machinery, however, has surprising behavior in one specific 
 case: Optional. If a user puts an optional value into a string 
 interpolation segment, it will insert either "Optional("value")" or "nil" 
 in the resulting string. Neither of these is particularly desirable, so we 
 propose a warning and fix-it to surface solutions to these potential 
 mistakes.
 
 Swift-evolution thread: Discussion thread topic for that proposal 
 
  
 Motivation
 
 The Swift Programming Language defines string interpolation segments as "a 
 way to construct a new String value from a mix of constants, variables, 
 literals, and expressions". There is one type that runs counter to this 
 definition: Optional. The .none case in particular is used to indicate the 
 absence of a value. Moreover, its inclusion in interpolation segments 
 leads to the dreaded "nil" in output that is often fed to UI elements. 
 Even barring that, interpolating a non-nil optional value yields 
 "Optional("value")", a result that is not useful even in logged output.
 
 Given that the Optional type is never fit for display to the end user, and 
 can often be a surprising find in the console, we propose that requesting 
 an Optional's debug description be an explicit act. This proposal now 
 requires a warning when using an expression of Optional type within a 
 string interpolation segment.
 
  
 Proposed
  solution
 
 The user will be warned after attempting to use an expression with type 
 Optional in a string interpolation segment. They will then be 

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Keith Smiley via swift-evolution]

+1 to this warning. We've been hit by this bug a bunch of times. Especially when
optionality of properties have been in flux.

Just yesterday: https://twitter.com/zefhous/status/782783999663943680

--
Keith Smiley

On 10/03, Harlan Haskins via swift-evolution wrote:
> Hey all,
>
> Julio Carrettoni, Robert Widmann, and I have been working on a proposal to 
> mitigate something that's burned us all since Swift 1. We'd love some 
> feedback!
>
> It's available here: 
> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd
>
> I've posted the current draft below.
>
> Thanks,
> Harlan Haskins
>
> Disallow Optionals in String Interpolation Segments
> Proposal: SE-
> Authors: Harlan Haskins, Julio Carrettoni, Robert Widmann
> Review Manager: TBD
> Status: Awaiting revie
> Introduction
>
> Swift developers frequently use string interpolation as a convenient, concise 
> syntax for interweaving variable values with strings. The interpolation 
> machinery, however, has surprising behavior in one specific case: 
> Optional. If a user puts an optional value into a string interpolation 
> segment, it will insert either "Optional("value")" or "nil" in the resulting 
> string. Neither of these is particularly desirable, so we propose a warning 
> and fix-it to surface solutions to these potential mistakes.
>
> Swift-evolution thread: Discussion thread topic for that proposal
>
> Motivation
>
> The Swift Programming Language defines string interpolation segments as "a 
> way to construct a new String value from a mix of constants, variables, 
> literals, and expressions". There is one type that runs counter to this 
> definition: Optional. The .none case in particular is used to indicate the 
> absence of a value. Moreover, its inclusion in interpolation segments leads 
> to the dreaded "nil" in output that is often fed to UI elements. Even barring 
> that, interpolating a non-nil optional value yields "Optional("value")", a 
> result that is not useful even in logged output.
>
> Given that the Optional type is never fit for display to the end user, and 
> can often be a surprising find in the console, we propose that requesting an 
> Optional's debug description be an explicit act. This proposal now requires a 
> warning when using an expression of Optional type within a string 
> interpolation segment.
>
> Proposed solution
>
> The user will be warned after attempting to use an expression with type 
> Optional in a string interpolation segment. They will then be offered a 
> fixit suggesting they explicitly request the debugDescription of the Optional 
> value instead.
>
> Detailed design
>
> Semantic analysis currently does not do much but guarantee the 
> well-formedness of expressions in interpolation segments. These are then fed 
> directly to String.init(stringInterpolationSegment:) and are run through the 
> runtime reflection system to generate a description. Semantic analysis will 
> be tweaked to inspect the result of solving an interpolation segment for an 
> Optional and will offer a fixit in that case.
>
> Impact on existing code
>
> As this is a warning, code written before this proposal will continue to 
> compile and run with the same semantics as before. Authors of code that makes 
> use of this unsafe pattern will be offered a migration path to the safer, 
> more explicit form.
>
> Alternatives considered
>
> A fixit that suggests a default value be inserted would be entirely 
> appropriate (following the style of the fixit introduced in SE-0140).
>
> Forbidding this pattern by hard error would make this proposal a breaking 
> change that is out of scope for this stage of Swift's development.
>
> A fixit that introduces a force-unwrapping would technically work as well, 
> however it would be fixing a dangerous operation with yet another dangerous 
> operation.
>
>
>
> Sent from my iPad

> ___
> 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

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Robert Widmann via swift-evolution]

Because the initializer here doesn’t take Any, it takes .

~Robert Widmann

> On Oct 3, 2016, at 2:00 PM, Harlan Haskins via swift-evolution 
>  wrote:
> 
> Unfortunately, Optional-to-Any does not currently hit this case because IIRC 
> it doesn't promote to Any in an interpolation segment. I tested this with a 
> ToT build yesterday.
> 
> - Harlan
> 
> On Oct 3, 2016, at 1:57 PM, Joe Groff  > wrote:
> 
>> We now emit a warning whenever an optional is used as an Any. I disagree 
>> that this should be an error, but it seems reasonable to warn (if we don't 
>> already thanks to the 'Any' warning).
>> 
>> -Joe
>> 
>>> On Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift-evolution 
>>> > wrote:
>>> 
>>> Hey all,
>>> 
>>> Julio Carrettoni, Robert Widmann, and I have been working on a proposal to 
>>> mitigate something that's burned us all since Swift 1. We'd love some 
>>> feedback!
>>> 
>>> It's available here: 
>>> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd 
>>> 
>>> 
>>> I've posted the current draft below.
>>> 
>>> Thanks,
>>> Harlan Haskins
>>> 
>>> Disallow Optionals in String Interpolation Segments
>>> 
>>> Proposal: SE- 
>>> Authors: Harlan Haskins , Julio 
>>> Carrettoni , Robert Widmann 
>>> 
>>> Review Manager: TBD
>>> Status: Awaiting revie
>>>  
>>> Introduction
>>> 
>>> Swift developers frequently use string interpolation as a convenient, 
>>> concise syntax for interweaving variable values with strings. The 
>>> interpolation machinery, however, has surprising behavior in one specific 
>>> case: Optional. If a user puts an optional value into a string 
>>> interpolation segment, it will insert either "Optional("value")" or "nil" 
>>> in the resulting string. Neither of these is particularly desirable, so we 
>>> propose a warning and fix-it to surface solutions to these potential 
>>> mistakes.
>>> 
>>> Swift-evolution thread: Discussion thread topic for that proposal 
>>> 
>>>  
>>> Motivation
>>> 
>>> The Swift Programming Language defines string interpolation segments as "a 
>>> way to construct a new String value from a mix of constants, variables, 
>>> literals, and expressions". There is one type that runs counter to this 
>>> definition: Optional. The .none case in particular is used to indicate the 
>>> absence of a value. Moreover, its inclusion in interpolation segments leads 
>>> to the dreaded "nil" in output that is often fed to UI elements. Even 
>>> barring that, interpolating a non-nil optional value yields 
>>> "Optional("value")", a result that is not useful even in logged output.
>>> 
>>> Given that the Optional type is never fit for display to the end user, and 
>>> can often be a surprising find in the console, we propose that requesting 
>>> an Optional's debug description be an explicit act. This proposal now 
>>> requires a warning when using an expression of Optional type within a 
>>> string interpolation segment.
>>> 
>>>  
>>> Proposed
>>>  solution
>>> 
>>> The user will be warned after attempting to use an expression with type 
>>> Optional in a string interpolation segment. They will then be offered a 
>>> fixit suggesting they explicitly request the debugDescription of the 
>>> Optional value instead.
>>> 
>>>  
>>> Detailed
>>>  design
>>> 
>>> Semantic analysis currently does not do much but guarantee the 
>>> well-formedness of expressions in interpolation segments. These are then 
>>> fed directly to String.init(stringInterpolationSegment:) and are run 
>>> through the runtime reflection system to generate a description. Semantic 
>>> analysis will be tweaked to inspect the result of solving an interpolation 
>>> segment for an Optional and will offer a fixit in that case.
>>> 
>>>  
>>> Impact
>>>  on existing code
>>> 
>>> As this is a warning, code written before this proposal will continue to 
>>> compile and run with the same semantics as before. Authors of code that 
>>> makes use of this unsafe pattern will be offered a migration path to the 
>>> safer, more explicit form.
>>> 
>>>  
>>> 

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Harlan Haskins via swift-evolution]

Unfortunately, Optional-to-Any does not currently hit this case because IIRC it 
doesn't promote to Any in an interpolation segment. I tested this with a ToT 
build yesterday.

- Harlan

> On Oct 3, 2016, at 1:57 PM, Joe Groff  wrote:
> 
> We now emit a warning whenever an optional is used as an Any. I disagree that 
> this should be an error, but it seems reasonable to warn (if we don't already 
> thanks to the 'Any' warning).
> 
> -Joe
> 
>> On Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift-evolution 
>>  wrote:
>> 
>> Hey all,
>> 
>> Julio Carrettoni, Robert Widmann, and I have been working on a proposal to 
>> mitigate something that's burned us all since Swift 1. We'd love some 
>> feedback!
>> 
>> It's available here: 
>> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd
>> 
>> I've posted the current draft below.
>> 
>> Thanks,
>> Harlan Haskins
>> 
>> Disallow Optionals in String Interpolation Segments
>> 
>> Proposal: SE-
>> Authors: Harlan Haskins, Julio Carrettoni, Robert Widmann
>> Review Manager: TBD
>> Status: Awaiting revie
>> Introduction
>> 
>> Swift developers frequently use string interpolation as a convenient, 
>> concise syntax for interweaving variable values with strings. The 
>> interpolation machinery, however, has surprising behavior in one specific 
>> case: Optional. If a user puts an optional value into a string 
>> interpolation segment, it will insert either "Optional("value")" or "nil" in 
>> the resulting string. Neither of these is particularly desirable, so we 
>> propose a warning and fix-it to surface solutions to these potential 
>> mistakes.
>> 
>> Swift-evolution thread: Discussion thread topic for that proposal
>> 
>> Motivation
>> 
>> The Swift Programming Language defines string interpolation segments as "a 
>> way to construct a new String value from a mix of constants, variables, 
>> literals, and expressions". There is one type that runs counter to this 
>> definition: Optional. The .none case in particular is used to indicate the 
>> absence of a value. Moreover, its inclusion in interpolation segments leads 
>> to the dreaded "nil" in output that is often fed to UI elements. Even 
>> barring that, interpolating a non-nil optional value yields 
>> "Optional("value")", a result that is not useful even in logged output.
>> 
>> Given that the Optional type is never fit for display to the end user, and 
>> can often be a surprising find in the console, we propose that requesting an 
>> Optional's debug description be an explicit act. This proposal now requires 
>> a warning when using an expression of Optional type within a string 
>> interpolation segment.
>> 
>> Proposed solution
>> 
>> The user will be warned after attempting to use an expression with type 
>> Optional in a string interpolation segment. They will then be offered a 
>> fixit suggesting they explicitly request the debugDescription of the 
>> Optional value instead.
>> 
>> Detailed design
>> 
>> Semantic analysis currently does not do much but guarantee the 
>> well-formedness of expressions in interpolation segments. These are then fed 
>> directly to String.init(stringInterpolationSegment:) and are run through the 
>> runtime reflection system to generate a description. Semantic analysis will 
>> be tweaked to inspect the result of solving an interpolation segment for an 
>> Optional and will offer a fixit in that case.
>> 
>> Impact on existing code
>> 
>> As this is a warning, code written before this proposal will continue to 
>> compile and run with the same semantics as before. Authors of code that 
>> makes use of this unsafe pattern will be offered a migration path to the 
>> safer, more explicit form.
>> 
>> Alternatives considered
>> 
>> A fixit that suggests a default value be inserted would be entirely 
>> appropriate (following the style of the fixit introduced in SE-0140).
>> 
>> Forbidding this pattern by hard error would make this proposal a breaking 
>> change that is out of scope for this stage of Swift's development.
>> 
>> A fixit that introduces a force-unwrapping would technically work as well, 
>> however it would be fixing a dangerous operation with yet another dangerous 
>> operation.
>> 
>> 
>> 
>> Sent from my iPad
>> ___
>> 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

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Joe Groff via swift-evolution]

We now emit a warning whenever an optional is used as an Any. I disagree that 
this should be an error, but it seems reasonable to warn (if we don't already 
thanks to the 'Any' warning).

-Joe

> On Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift-evolution 
>  wrote:
> 
> Hey all,
> 
> Julio Carrettoni, Robert Widmann, and I have been working on a proposal to 
> mitigate something that's burned us all since Swift 1. We'd love some 
> feedback!
> 
> It's available here: 
> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd 
> 
> 
> I've posted the current draft below.
> 
> Thanks,
> Harlan Haskins
> 
> Disallow Optionals in String Interpolation Segments
> 
> Proposal: SE- 
> Authors: Harlan Haskins , Julio Carrettoni 
> , Robert Widmann 
> 
> Review Manager: TBD
> Status: Awaiting revie
>  
> Introduction
> 
> Swift developers frequently use string interpolation as a convenient, concise 
> syntax for interweaving variable values with strings. The interpolation 
> machinery, however, has surprising behavior in one specific case: 
> Optional. If a user puts an optional value into a string interpolation 
> segment, it will insert either "Optional("value")" or "nil" in the resulting 
> string. Neither of these is particularly desirable, so we propose a warning 
> and fix-it to surface solutions to these potential mistakes.
> 
> Swift-evolution thread: Discussion thread topic for that proposal 
> 
>  
> Motivation
> 
> The Swift Programming Language defines string interpolation segments as "a 
> way to construct a new String value from a mix of constants, variables, 
> literals, and expressions". There is one type that runs counter to this 
> definition: Optional. The .none case in particular is used to indicate the 
> absence of a value. Moreover, its inclusion in interpolation segments leads 
> to the dreaded "nil" in output that is often fed to UI elements. Even barring 
> that, interpolating a non-nil optional value yields "Optional("value")", a 
> result that is not useful even in logged output.
> 
> Given that the Optional type is never fit for display to the end user, and 
> can often be a surprising find in the console, we propose that requesting an 
> Optional's debug description be an explicit act. This proposal now requires a 
> warning when using an expression of Optional type within a string 
> interpolation segment.
> 
>  
> Proposed
>  solution
> 
> The user will be warned after attempting to use an expression with type 
> Optional in a string interpolation segment. They will then be offered a 
> fixit suggesting they explicitly request the debugDescription of the Optional 
> value instead.
> 
>  
> Detailed
>  design
> 
> Semantic analysis currently does not do much but guarantee the 
> well-formedness of expressions in interpolation segments. These are then fed 
> directly to String.init(stringInterpolationSegment:) and are run through the 
> runtime reflection system to generate a description. Semantic analysis will 
> be tweaked to inspect the result of solving an interpolation segment for an 
> Optional and will offer a fixit in that case.
> 
>  
> Impact
>  on existing code
> 
> As this is a warning, code written before this proposal will continue to 
> compile and run with the same semantics as before. Authors of code that makes 
> use of this unsafe pattern will be offered a migration path to the safer, 
> more explicit form.
> 
>  
> Alternatives
>  considered
> 
> A fixit that suggests a default value be inserted would be entirely 
> appropriate (following the style of the fixit introduced in SE-0140 
> ).
> 
> Forbidding this pattern by hard error would make this proposal a breaking 
> change that is out of scope for this stage of Swift's development.
> 
> A fixit that introduces a force-unwrapping would technically work as well, 
> however it would be fixing a dangerous operation with yet another dangerous 
> operation.
> 
> 
> 
> Sent from my iPad
> ___
> swift-evolution mailing list
> 

[swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Harlan Haskins via swift-evolution]

Hey all,

Julio Carrettoni, Robert Widmann, and I have been working on a proposal to 
mitigate something that's burned us all since Swift 1. We'd love some feedback!

It's available here: 
https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd

I've posted the current draft below.

Thanks,
Harlan Haskins

Disallow Optionals in String Interpolation Segments
Proposal: SE-
Authors: Harlan Haskins, Julio Carrettoni, Robert Widmann
Review Manager: TBD
Status: Awaiting revie
Introduction

Swift developers frequently use string interpolation as a convenient, concise 
syntax for interweaving variable values with strings. The interpolation 
machinery, however, has surprising behavior in one specific case: Optional. 
If a user puts an optional value into a string interpolation segment, it will 
insert either "Optional("value")" or "nil" in the resulting string. Neither of 
these is particularly desirable, so we propose a warning and fix-it to surface 
solutions to these potential mistakes.

Swift-evolution thread: Discussion thread topic for that proposal

Motivation

The Swift Programming Language defines string interpolation segments as "a way 
to construct a new String value from a mix of constants, variables, literals, 
and expressions". There is one type that runs counter to this definition: 
Optional. The .none case in particular is used to indicate the absence of a 
value. Moreover, its inclusion in interpolation segments leads to the dreaded 
"nil" in output that is often fed to UI elements. Even barring that, 
interpolating a non-nil optional value yields "Optional("value")", a result 
that is not useful even in logged output.

Given that the Optional type is never fit for display to the end user, and can 
often be a surprising find in the console, we propose that requesting an 
Optional's debug description be an explicit act. This proposal now requires a 
warning when using an expression of Optional type within a string interpolation 
segment.

Proposed solution

The user will be warned after attempting to use an expression with type 
Optional in a string interpolation segment. They will then be offered a 
fixit suggesting they explicitly request the debugDescription of the Optional 
value instead.

Detailed design

Semantic analysis currently does not do much but guarantee the well-formedness 
of expressions in interpolation segments. These are then fed directly to 
String.init(stringInterpolationSegment:) and are run through the runtime 
reflection system to generate a description. Semantic analysis will be tweaked 
to inspect the result of solving an interpolation segment for an Optional and 
will offer a fixit in that case.

Impact on existing code

As this is a warning, code written before this proposal will continue to 
compile and run with the same semantics as before. Authors of code that makes 
use of this unsafe pattern will be offered a migration path to the safer, more 
explicit form.

Alternatives considered

A fixit that suggests a default value be inserted would be entirely appropriate 
(following the style of the fixit introduced in SE-0140).

Forbidding this pattern by hard error would make this proposal a breaking 
change that is out of scope for this stage of Swift's development.

A fixit that introduces a force-unwrapping would technically work as well, 
however it would be fixing a dangerous operation with yet another dangerous 
operation.



Sent from my iPad___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution