On Mon, Aug 15, 2016 at 7:03 PM, Tim Vermeulen <tvermeu...@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?
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).
On 16 Aug 2016, at 00:51, Xiaodi Wu <xiaodi...@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@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.huenenber...@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 <tvermeu...@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.huenenber...@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 <tvermeu...@me.com>:
>>
>> You can’t; the `first` parameter has type `T`, not `T?`.
>>
>> On 15 Aug 2016, at 22:10, Maximilian Hünenberger <m.huenenber...@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@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@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
