[swift-evolution] Passing an optional first argument to sequence(first:next:)

[Xiaodi Wu]

On Mon, Aug 15, 2016 at 8:43 PM, Tim Vermeulen <tvermeulen at me.com> wrote:

> Point taken, in theory it is possible that someone’s program would change
> unexpectedly if we change the function’s signature. But wouldn’t you agree
> that this was a very contrived example? I can’t think of a lot more than
> converting it to a string that works on both optionals and non-optionals.
>
> `sequence(first:next:)` has only been available in Swift 3 beta versions,
> which are known to change over time. Shouldn’t we be focused on getting the
> function signature just right before Swift 3 is released?
>

If you can slip it in before the deadline, I think I'd be in favor. IIUC,
the window for landing that change is days if not hours. If it misses the
deadline, IMO checking for nil isn't terrible, but making a source-breaking
change would be.

On 16 Aug 2016, at 02:41, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> On Mon, Aug 15, 2016 at 7:23 PM, Tim Vermeulen <tvermeulen at me.com> wrote:
>
>>
>> On 16 Aug 2016, at 02:11, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>
>> On Mon, Aug 15, 2016 at 7:03 PM, Tim Vermeulen <tvermeulen at me.com> wrote:
>>
>>> If I'm not mistaken, the type of T can be inferred from the `next`
>>> closure here. $0 is an optional, so you end up with a sequence of optionals.
>>>
>>
>> Currently, yes. But if we have both
>>
>> public func sequence<T>(first: T, next: @escaping (T) -> T?) ->
>> UnfoldFirstSequence<T> { ... }
>> public func sequence<T>(first: T?, next: @escaping (T) -> T?) ->
>> UnfoldFirstSequence<T> { ... }
>>
>> then $0 could be inferred to be of type `T` or `T?`, right?
>>
>>
>> I was indeed talking about replacing the first function by the second,
>> not having them side by side.
>>
>>
>> And if we replace the first function with the second (instead of having
>> both), then the same code that gives you an UnfoldFirstSequence<T?> today
>> would give you an UnfoldFirstSequence<T> tomorrow, which would be the most
>> pernicious way to break code (subtle, hard to catch unless you know what
>> you're looking for, with a potentially massive difference in behavior).
>>
>>
>> I’m not sure I follow. First of all, I think an unfold sequence with an
>> optional element is pretty far-fetched, but fair enough, they may exist.
>> But why would the type suddenly change? Type inference would still figure
>> out the right type, no? An example would be greatly appreciated, because I
>> don’t see how this could form a problem.
>>
>
>
> ```
> // This function is silly,
> // but useful functions may take a similar form
> func foo(_ x: Int?) -> Int? {
>   guard let x = x else { return 0 }
>   return x > 12 ? nil : x + 1
> }
>
> let a: Int? = nil
> for i in sequence(first: a, next: { foo($0) }) {
>   // This is a pretty useless thing to do,
>   // but there are useful things that can be done
>   // without checking whether `i == nil`
>   print(i)
> }
> ```
>
> If you change the function signature, the number of lines printed by this
> example code will change from 14 to 0.
>
>
> On 16 Aug 2016, at 00:51, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>>
>>> Given:
>>>
>>> let foo: T? = something()
>>> let bar = sequence(first: foo, next: { $0?.frobnicate() })
>>>
>>> If first could be of type `T` or `T?`, is bar of type
>>> `UnfoldSequence<T>` or `UnfoldSequence<T?>`?
>>> On Mon, Aug 15, 2016 at 17:15 Tim Vermeulen via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>>> I doubt that’s it, in no way is an an empty sequence inherently unsafe.
>>>> The entire standard library is built with empty sequences in mind. I’m more
>>>> inclined to think it’s an oversight.
>>>>
>>>> On 15 Aug 2016, at 23:15, Maximilian Hünenberger <m.huenenberger at me.com>
>>>> wrote:
>>>>
>>>> Ok, I see. However this could be a potential source of bugs/performance
>>>> issues where you don't consider the nil case and you do some unnecessary
>>>> work. By prohibiting to pass nil you have to manually unwrap and you
>>>> immediately see the "optionality".
>>>>
>>>> Am 15.08.2016 um 22:36 schrieb Tim Vermeulen <tvermeulen at me.com>:
>>>>
>>>> Oh, that’s true, I misunderstood your previous message. It’s not about
>>>> passing nil, but it’s about passing optionals. The point is to be able to
>>>> do something like this:
>>>>
>>>> let number = functionThatReturnsAnOptional()
>>>> sequence(first: number, next: { $0 % 2 == 0 ? $0 / 2 : nil })
>>>>
>>>> On 15 Aug 2016, at 22:26, Maximilian Hünenberger <m.huenenberger at me.com>
>>>> wrote:
>>>>
>>>> Probably I didn't understand your proposal. What do you want to change
>>>> exactly?
>>>>
>>>> I thought:
>>>> public func sequence<T>(first: T, next: @escaping (T) -> T?) ->
>>>> UnfoldFirstSequence<T> { ... }
>>>>
>>>> To:
>>>> public func sequence<T>(first: T?, next: @escaping (T) -> T?) ->
>>>> UnfoldFirstSequence<T> { ... }
>>>>
>>>> Am 15.08.2016 um 22:17 schrieb Tim Vermeulen <tvermeulen at me.com>:
>>>>
>>>> You can’t; the `first` parameter has type `T`, not `T?`.
>>>>
>>>> On 15 Aug 2016, at 22:10, Maximilian Hünenberger <m.huenenberger at me.com>
>>>> wrote:
>>>>
>>>> Hi Tim,
>>>>
>>>> If you pass "nil" to "first" isn't this an empty sequence? So it would
>>>> be redundant.
>>>>
>>>> Best regards
>>>> Maximilian
>>>>
>>>> Am 15.08.2016 um 01:27 schrieb Tim Vermeulen via swift-evolution <
>>>> swift-evolution at swift.org>:
>>>>
>>>> sequence(first:next:) takes a non-optional first argument. Is there a
>>>> reason for that? sequence(state:next:) allows empty sequences, and I don’t
>>>> see why sequence(first:next:) shouldn’t. The fix would be to simply add the
>>>> `?` in the function signature; no other changes are required to make it
>>>> work.
>>>>
>>>> I considered just filing a bug report, but since this is a change of
>>>> the public API...
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160815/5d099ad7/attachment.html>