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

[Jordan Rose]

> On Jul 1, 2016, at 15:53, Russ Bishop <xenadu at gmail.com> wrote:
> 
> 
>> On Jun 30, 2016, at 4:23 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> [Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0108-remove-assoctype-inference.md <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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> I’m trying to fill a gap in my own knowledge here. How does explicitly stating that startIndex is the inference point for Index help? 
> 
> Is it because various extensions and default implementations can provide different concrete types for Index, so the type checker is trying to resolve the ambiguity? If that’s the case, specifying startIndex here restricts the defaults/extensions that need to be considered from all to just ones that implement startIndex? Is that good enough generally or does it just solve the standard library’s problems?
> 
> Would it be enough to have rules along these lines for a concrete type adopting a protocol with associated types?
> 
> 1. If the type’s main declaration (not defaults or extensions) contains a member satisfying a protocol requirement (where the requirement is specified in terms of an associated type) the associated type is locked to the type used in that member, so no global inference is necessary. If more than one such member is present all must use the same exact type.
> 2. Otherwise if there exists only one default/extension satisfying the associated type, the type used in that default implementation is used.
> 3. In all other cases the user must specify the associated types explicitly.

I don't remember exactly how the current rules work, but I think the compiler looks at all the members that mention an associated type and tries to figure out if they're all in sync. Reducing that to just looking at one value requirement might be enough to satisfy Doug's concerns, even if it still has to do overload resolution…or you could follow the spirit of your rule 2 and say that any overloads force you to specify the element type explicitly.

Rule 1, however, is the important one: "if more than one such member is present all must use the same exact type". I think that's already moving into the realm of spooky action and circularity issues that Doug's attempting to squash.

Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160706/9cc142c5/attachment.html>