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@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 <austinzh...@gmail.com
>> <mailto:austinzh...@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
