[swift-evolution] [Pitch] Remove associated type inference

[Matthew Johnson]

Sent from my iPad

> On May 25, 2016, at 6:11 PM, Dmitri Gribenko via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Wed, May 25, 2016 at 3:42 PM, Leonardo Pessoa <me at lmpessoa.com> wrote:
>>> On Wednesday, 25 May 2016, Dmitri Gribenko via swift-evolution <swift-evolution at swift.org> wrote:
>>> On Wed, May 25, 2016 at 2:52 PM, David Hart <david at hartbit.com> wrote:
>>> >
>>> >> On 25 May 2016, at 23:47, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>>> >>
>>> >> On Wed, May 25, 2016 at 2:43 PM, David Hart via swift-evolution
>>> >> <swift-evolution at swift.org> wrote:
>>> >>> Impact on Existing Code
>>> >>>
>>> >>> This is a breaking change that will require conforming types which relied on
>>> >>> the inference, including in the Standard Library, to explicitly declare
>>> >>> associated types. A Fix-It could be introduced to add the typealias and
>>> >>> leave the type to be filled in. That way, all the type inference could be
>>> >>> removed from the compiler.
>>> >>
>>> >> Please show an example -- for example, what a smallest collection type
>>> >> will look like.
>>> >
>>> > Isn’t that the example in the Detailed Design section? What other example were you thinking of?
>>> 
>>> You are showing an iterator.  Try doing a collection, it has many more
>>> associated types most of which are defaulted.
>>> 
>>> >>> Alternatives Considered
>>> >>>
>>> >>> The only alternative is to keep the inference with the known consequences on
>>> >>> the compiler.
>>> >>
>>> >> Sorry, that's not fair :)  There is a middle ground -- limited
>>> >> inference.  For example, in Collection, we don't need Index to be
>>> >> inferrable from every declaration that mentions it.  We can add a
>>> >> feature to declare that the type of 'var startIndex' infers
>>> >> 'associatedtype Index' (via an appropriate attribute).  It is true
>>> >> that this approach would not remove global inference as such, but it
>>> >> will make it a much easier problem I believe.
>>> >
>>> > This sounds like a more complicated solution: it does not remove global inference and complicates the language with an additional attribute only to help the compiler. I don’t see many advantages to this solution.
>>> 
>>> The advantage is that we can keep the boilerplate down, and make the
>>> problem easier in the compiler.
>> 
>> If the issue is easing the work of the compiler, are you suggesting dropping the entire type inference? I don't really think removing it here will "solve" anything.
> 
> 
> No, I'm suggesting to limit the scope.
> 
> protocol Collection {
>   typealias Index
>   @infers(Index)
>   var startIndex: Index { get }
>   var endIndex: Index { get }
>   subscript(i: Index) -> Iterator.Element
> }
> 
> Here, only 'var startIndex' in a conforming type would be causing 'Index' to be inferred.  'endIndex' and subscript won't have any effect on the inference.  My suggestion is that we will only allow one such declaration to exist.  This is a much simpler problem, I think, than solving a constraint system that involves all declarations that mention Index (as it is now).

And IMO it's much more acceptable to do something like this that only impacts protocol declarations than to remove associated type inference altogether and place a burden on every conformance.

> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
> _______________________________________________
> 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/20160525/7ed9982b/attachment.html>