> On 16 Aug 2016, at 02:11, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Mon, Aug 15, 2016 at 7:03 PM, Tim Vermeulen <tvermeu...@me.com > <mailto: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?
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. > > > On 16 Aug 2016, at 00:51, Xiaodi Wu <xiaodi...@gmail.com > <mailto: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 <mailto: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 >>> <mailto: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 >>> <mailto: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 >>>>> <mailto: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 >>>>>> <mailto: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 >>>>>>> <mailto: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 <mailto: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 <mailto:swift-evolution@swift.org> >>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>> >>>> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
