[swift-evolution] [swift-evolution-announce] [Review] SE-0108: Remove associated type inference

[T.J. Usiyan]

        * What is your evaluation of the proposal?
+ 1
        * Is the problem being addressed significant enough to warrant a
change to Swift?
Yes. When inference goes wrong it is frustrating and difficult to puzzle
out.
        * Does this proposal fit well with the feel and direction of Swift?
Yes. I agree that a keyword for explicitly invoking inference would also
work if it meant that the process would be consistent. The ability to add
type aliases to protocol extensions is welcome as well.
        * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
A couple readings.

On Thu, Jun 30, 2016 at 7:23 PM, Jordan Rose via swift-evolution <
swift-evolution at swift.org> wrote:

> [Proposal:
> https://github.com/apple/swift-evolution/blob/master/proposals/0108-remove-assoctype-inference.md
>  ]
>
> I’m pretty concerned about completely removing this feature. Yes, it’s a
> type-checker / decl-checker nightmare, but I think Paolo’s example in the
> initial discussion showed how it’s being used effectively today. I’d much
> rather have some kind of inference marker that maps one-to-one between an
> associated type and a value requirement (method, initializer, property, or
> subscript), also as brought up in the original discussion.
>
> protocol OptionA {
>   associatedtype Index
>
>   @infers(Index)
>   var startIndex: Index { get }
>
>   var endIndex: Index { get }
> }
>
> protocol OptionB {
>   @inferredFrom(startIndex) // allows a full name here for overload
> resolution
>   associatedtype Index
>
>   var startIndex: Index { get }
>   var endIndex: Index { get }
> }
>
> protocol OptionC {
>   associatedtype Index in startIndex // sugar
>
>   var startIndex: Index { get }
>   var endIndex: Index { get }
> }
>
>
> OptionC is the prettiest, but OptionA is probably the most flexible
> (consider overloading on associated types).
>
> I know we want to lock down on things now, and I know we can do better in
> the future, but I think inferring associated types is really quite common,
> and I’m concerned about taking it out without giving people a good
> alternative. This *is* just an impression, though.
>
> Jordan
>
> _______________________________________________
> 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/20160701/9b7c8997/attachment.html>