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

[Leonardo Pessoa]

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
> <javascript:;>> wrote:
> >
> >> On 25 May 2016, at 23:47, Dmitri Gribenko <gribozavr at gmail.com
> <javascript:;>> wrote:
> >>
> >> On Wed, May 25, 2016 at 2:43 PM, David Hart via swift-evolution
> >> <swift-evolution at swift.org <javascript:;>> 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.


>
> 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
> <javascript:;>>*/
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <javascript:;>
> 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/9d597542/attachment.html>