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

[Charlie Monroe]

I'm not quite what would be the behavior of this in the proposal:

extension IntBag : StringBag {
    associatedtype Element = Element
}

since both IntBag and StringBag are classes - would IntBag use StringBag's code, but replace String with Int? Or would it just contain both 

func object(at index: Int) -> Int?

and

func object(at index: Int) -> String?

if that is the case, what if the protocol contains a non-generic function like

func countElements() -> Int

?


> On Jun 25, 2016, at 8:35 PM, Austin Zheng via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hi all,
> 
> Thank you for all your comments and feedback! I've rewritten and expanded the proposal to address as many peoples' concerns as possible.
> 
> Best,
> Austin
> 
>> On Jun 24, 2016, at 10:50 PM, Austin Zheng <austinzheng at gmail.com <mailto:austinzheng at gmail.com>> wrote:
>> 
>> Hello all,
>> 
>> Per Chris Lattner's list of open Swift 3 design topics (http://article.gmane.org/gmane.comp.lang.swift.evolution/21369 <http://article.gmane.org/gmane.comp.lang.swift.evolution/21369>), I've put together a proposal for removing type inference for associated types.
>> 
>> It can be found here: https://github.com/austinzheng/swift-evolution/blob/az-assoctypeinf/proposals/XXXX-remove-assoctype-inference.md <https://github.com/austinzheng/swift-evolution/blob/az-assoctypeinf/proposals/XXXX-remove-assoctype-inference.md>
>> 
>> Thoughts, criticism, and feedback welcome. There are at least two slightly different designs in the proposal, and I'm sure people will have ideas for even more.
>> 
>> Best,
>> Austin
> 
> _______________________________________________
> 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/20160627/a5d64bbc/attachment.html>