Questions about the future of Protocols with Associated Types

[regexident (Vincent Esche)]

@Dante-Broggi

protocol Bindable<T> { // … associatedtype Flattenable: Bindable = Self func flatMap(_ transform: (Self.Element) throws -> Flattenable) rethrows → Output<Flattenable.Element> }

Fixed, thanks!

[Dante-Broggi]

Sorry, but there was map and compactMap functions in Bindable that should have stayed.
that was what the "// …" was signifying in my post.

[ebg]

Is there an actual priority list to share? Or a way the community can influence the list? Obviously everyone will have slightly different wants from Swift, e.g. I find this to be the highest priority feature to make Swift work how my brain wants it to work, but others value ABI stability first. Is there a gauge on Swift developers' interests, understanding that those who post here are the smallest minority of users?

[anandabits (Matthew Johnson)]

The priorities and focus area for each release are chosen by the core team. The current priorities (for Swift 5) are documented in the readme for the evolution repo: GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language..

[Jon_Hull]

What are the specific issues that need to be designed/addressed?

It may not be at the top of the implementation priority list, but that doesn't mean we can't do actual design work as a community while we wait (and there is always a chance it could piggyback on the implementation of one of the other generics changes, if we are re-writing code anyway).

I can't think of a feature which would do more to relieve coding frustration in Swift. I run into this all the time.

[jrose (Jordan Rose)]

@Jon_Hull

What are the specific issues that need to be designed/addressed?

It may not be at the top of the implementation priority list, but that doesn't mean we can't do actual design work as a community while we wait (and there is always a chance it could piggyback on the implementation of one of the other generics changes, if we are re-writing code anyway).

This is a good question. The primary one is what happens to associated types that are not constrained. That is, if I have a Collection where Element == Int (or however we end up spelling this), what happens when I ask for the startIndex? If I have two Comparable values, how does the compiler tell me I still can't use <?

(The simplest answer to the first question is that you're just not allowed to do this, but that makes Collection where Element == Int nearly unusable. It's not just indexes you can't get; it's slices and iterators too.)

[anandabits (Matthew Johnson)]

@jrose

This is a good question. The primary one is what happens to associated types that are not constrained. That is, if I have a Collection where Element == Int (or however we end up spelling this), what happens when I ask for the startIndex ? If I have two Comparable values, how does the compiler tell me I still can't use < ?

(The simplest answer to the first question is that you're just not allowed to do this, but that makes Collection where Element == Int nearly unusable. It's not just indexes you can't get; it's slices and iterators too.)

I really like the design that @Austin drafted a couple years ago. It addresses questions like this starting here. It needs to be updated for the current state of Swift, but otherwise I think it is an excellent place to start. @jrose what is your opinion on the big design decisions made by that draft?