> On Jun 29, 2016, at 4:38 PM, Brent Royal-Gordon via swift-evolution
> <[email protected]> wrote:
>
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0108-remove-assoctype-inference.md
>
>> * What is your evaluation of the proposal?
>
> I don't think the time is right.
>
> I've been reading the code for Sequence, Collection, and the various
> protocols that they use (I actually went to bed with an almost finished email
> for the discussion thread), and I think this is going to be a big problem
> there. From what I can see, there are two places where they lean heavily on
> inference for basic usability:
>
> 1. `Sequence.SubSequence` has no default type, but it is inferred to be
> `AnySequence<Iterator.Element>` in the absence of an alternative, because the
> standard library provides an extension full of
> `AnySequence<Iterator.Element>`-returning implementations. Honestly, I'm not
> sure why it doesn't have a default—some very basic testing in the REPL didn't
> seem to show any circularity problems—so my guess is that this one could be
> resolved.
>
> 2. `Collection._Element` (actually `IndexableBase._Element`) is a *hidden*
> associated type which uses inference to break a nasty loop between
> `Collection` and `IndexingIterator`. (`IndexingIterator` wants to use the
> `Iterator.Element` of the collection it's used with, but if that `Iterator`
> is itself `IndexingIterator`, that would be a circular definition. Instead,
> it uses the collection's `_Element`, which is inferred to be the return type
> of the index subscript.) Without inference, we would have two options here,
> neither of them great:
>
> a. Make `Collection.Element` a publicly visible associated type.
> Because we don't have `where` clauses for associated types yet, that would
> make it very easy to create a Collection whose `Element` and
> `Iterator.Element` did not match. (If we *do* make it a non-hidden associated
> type, I would suggest we add same-named generic parameters as another way to
> implicitly fulfill an associated type requirement; that would handle many
> collections automatically.)
>
> b. Make the element type a second generic parameter to
> `IndexingIterator`. This would effectively prevent us from offering a default
> `Iterator` on `Collection`s.
>
> Additionally, I believe the other un-defaulted associated types we'd like to
> infer if we can—`Collection.Index`, `Sequence.Iterator`, and
> `IteratorProtocol.Element`—could all be handled by simple "caveman inference"
> heuristics, rather than a full type inference pass. All three of these are
> used in either the types of un-defaulted properties (which cannot ever be
> overloaded) or the return types of un-defaulted nullary methods (which can be
> overloaded but rarely are). If we could use only those limited cases to guess
> the appropriate types, then plug them in and see if they typecheck, that
> would go a long way towards softening the blow of removing associated type
> inference.
>
> So, in summary:
>
> • I think that removing associated type inference will seriously impair
> Collection's usability and type-safety.
The usability argument I understand. It’s a big, open question. I hacked up a
flag for swiftc (-Xfrontend -disable-associated-type-witness-inference) on this
branch:
https://github.com/apple/swift/tree/disable-associated-type-witness-inference
that simply disables associated type witness inference so we can experiment. If
we do nothing to the standard library, the experience is awful for (e.g.) the
case of a type that minimally conforms to today’s Collection. But we knew the
standard library would need changes, because it heavily depends on this
inference today, so we won’t have a good sense of what we can accomplish until
someone actually tries to work with the proposed restriction. I, personally,
don’t have the time to invest in this right now :(
> • I think that these issues ought to be mitigated in the future by new
> compiler features which we may not have the time to implement before we ship
> Swift 3.
You're talking about recursive protocol constraints (which would help collapse
some of the underscored protocols) and where clauses on associated types in
particular?
- Doug
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
