> > On Aug 20, 2016, at 02:26, Tim
> > Vermeulen<[email protected](mailto:[email protected])>wrote:
> > What you’re saying makes sense, and I might not have brought this up in the
> > first place if `first.map { sequence(first: $0, next: next } ?? []` worked.
> > The main annoyance is that the best solution (currently) seems to be to
> > copy the source code and make a change.
> >
> > (cc-ing Jordan Rose because of a related swift-users thread) This might be
> > a bit of a stretch, but can’t Swift upcast sequences to AnySequence
> > implicitly, like is done with AnyHashable? That would make `first.map {
> > sequence(first: $0, next: next } ?? []` instantly valid, I think. There’s
> > also something to be said for consistency between type erasers. (I’m not
> > necessarily talking about Swift 3)
> Sorry to let this sit. I really would not want to implement this by upcasting
> to AnySequence. That would be tremendously inefficient.
Maybe I misunderstood, but when would that be inefficient? Most of all,
implicit upcasting to AnySequence would make functions that return AnySequence
cleaner. That’s unrelated to the sequence(first:next:) issue, but it certainly
wouldn’t be any less efficient than explicit casting to AnySequence.
As for the sequence(first:next:) thing, implicit casting to AnySequence would
allow us to write `first.map { sequence(first: $0, next: next) } ?? []` without
having to wrap both operands in an AnySequence explicitly. That wouldn’t just
help for this particular case, but in any situation where you want to iterate
over an optional sequence - I usually see people “fix” that with
`optionalSequence?.forEach { }`, but I think most people would rather write
`for element in optionalSequence ?? [] { }` instead. But maybe this is what you
were referring to when you said it’d be very inefficient?
In any case, this topic isn’t really relevant in this time period, as it’s
purely additive. As you pointed out, so is the `sequence(first:next:)`
suggestion (mostly); would it be better if I brought this up again at a later
time?
> In general, AnyHashable is special because of dictionary literals, where the
> same thing would have to be specified over and over again. That’s not true
> here. (And we weren’t even going to do it for AnyHashable originally.)
>
> I’m mildly in favor of the very original form of this proposal,
>
> > func sequence(first: T?, next: @escaping (T) ->T?) ->UnfoldFirstSequence<T>
> It’s also very nearly an additive change; the only existing code that would
> change meaning is that IUOs would not cause traps. (And the contrived
> examples with almost no type information, where the user iscurrentlytrying to
> infer T = Optional<X>and return a sequence of Optional<X>.)
> Jordan_______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
