[swift-evolution] Casting Bug Swift

[Joe Groff]

> On Feb 25, 2016, at 12:07 PM, Radek Pietruszewski <radexpl at gmail.com> wrote:
> 
> Hm. Obviously, you have far more insight into current implementation and performance difficulties, but purely from a programmer's perspective, going from [Foo] to AnyCollection<Foo> and from 'xs as? [Bar]' to 'xs.mapAsType(Bar.self)' seems like a step back.

True. This is all just ideas at this point. If we were serious about changing the currency type for collections, we'd probably want to change the type sugar to match.

-Joe

> 
> Regarding the latter, wouldn't it be better to somehow generalize covariant collection casts? Perhaps a special protocol different collection types can conform to to define their cast implementation?
> 
> Sent from my iPhone
> 
>> On 25 Feb 2016, at 20:50, Joe Groff <jgroff at apple.com> wrote:
>> 
>> 
>>> On Feb 25, 2016, at 11:45 AM, Radek Pietruszewski <radexpl at gmail.com> wrote:
>>> 
>>> Interesting. Two Qs:
>>> 
>>> - when you say "moving in the direction of encouraging the use of abstract AnyCollection values", do you mean in general? To encourage people to use AnyCollection<T> instead of [T] in their code?
>> 
>> Yeah. In Cocoa, the NSArray and NSDictionary class clusters serve the purpose not only of standard collections but as abstract interfaces for ordered and keyed collections, after all.
>> 
>>> - how could covariant collection casting look like in this world?
>> 
>> A no-language-support-needed approach might be to give the CollectionType protocol a `mapToType(T.self)` method which can be given specialized implementations for cases that can be efficiently implemented (such as mapping an array of class references to another class type), and/or fall back to wrapping with a lazy adapter in cases like going from a collection of ConcreteType to a collection of ProtocolType.
>> 
>> -Joe