<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 25, 2016 at 3:42 PM, Leonardo Pessoa <span dir="ltr"><<a href="mailto:me@lmpessoa.com" target="_blank">me@lmpessoa.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wednesday, 25 May 2016, Dmitri Gribenko via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, May 25, 2016 at 2:52 PM, David Hart <<a>david@hartbit.com</a>> wrote:<br>
><br>
>> On 25 May 2016, at 23:47, Dmitri Gribenko <<a>gribozavr@gmail.com</a>> wrote:<br>
>><br>
>> On Wed, May 25, 2016 at 2:43 PM, David Hart via swift-evolution<br>
>> <<a>swift-evolution@swift.org</a>> wrote:<br>
>>> Impact on Existing Code<br>
>>><br>
>>> This is a breaking change that will require conforming types which relied on<br>
>>> the inference, including in the Standard Library, to explicitly declare<br>
>>> associated types. A Fix-It could be introduced to add the typealias and<br>
>>> leave the type to be filled in. That way, all the type inference could be<br>
>>> removed from the compiler.<br>
>><br>
>> Please show an example -- for example, what a smallest collection type<br>
>> will look like.<br>
><br>
> Isn’t that the example in the Detailed Design section? What other example were you thinking of?<br>
<br>
You are showing an iterator. Try doing a collection, it has many more<br>
associated types most of which are defaulted.<br>
<br>
>>> Alternatives Considered<br>
>>><br>
>>> The only alternative is to keep the inference with the known consequences on<br>
>>> the compiler.<br>
>><br>
>> Sorry, that's not fair :) There is a middle ground -- limited<br>
>> inference. For example, in Collection, we don't need Index to be<br>
>> inferrable from every declaration that mentions it. We can add a<br>
>> feature to declare that the type of 'var startIndex' infers<br>
>> 'associatedtype Index' (via an appropriate attribute). It is true<br>
>> that this approach would not remove global inference as such, but it<br>
>> will make it a much easier problem I believe.<br>
><br>
> 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.<br>
<br>
The advantage is that we can keep the boilerplate down, and make the<br>
problem easier in the compiler.</blockquote><div><br></div></div></div><div>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.</div><div></div></blockquote></div><div class="gmail_extra"><br></div>No, I'm suggesting to limit the scope.</div><div class="gmail_extra"><br></div><div class="gmail_extra">protocol Collection {</div><div class="gmail_extra"> typealias Index</div><div class="gmail_extra"> @infers(Index)</div><div class="gmail_extra"> var startIndex: Index { get }</div><div class="gmail_extra"> var endIndex: Index { get }</div><div class="gmail_extra"> subscript(i: Index) -> Iterator.Element</div><div class="gmail_extra">}<br><br>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).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Dmitri<br clear="all"><div><br></div>-- <br><div class="gmail_signature">main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if<br>(j){printf("%d\n",i);}}} /*Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com" target="_blank">gribozavr@gmail.com</a>>*/</div>
</div></div>