[swift-evolution] Casting Bug Swift

[Radek Pietruszewski]

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?
- how could covariant collection casting look like in this world?

Sent from my iPhone

> On 25 Feb 2016, at 20:12, Joe Groff <jgroff at apple.com> wrote:
> 
> 
>> On Feb 25, 2016, at 9:07 AM, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> I think there are two things going on here:
>> 
>> - The compiler allows a memory-corrupting cast, which should be rejected (a bug).
>> - But it's a useful thing to do (a language change).
>> 
>> I'm actually surprised about the bug, since we get plenty of questions about why the compiler doesn't allow it, implying that the compiler is indeed rejecting it. The answer is that protocol values and class values don't have the same representation, so converting between [Eatable] and [Burger] is an O(N) operation that requires allocating a new array. But that may not be a good enough reason not to allow it—conversions from NSArray to Array can do the same thing if the NSArray was mutable.
> 
> I've overheard discussion of removing the covariant container conversions altogether, since they're inconsistent with the rest of the language, lead to a lot of type-checker and runtime dynamic cast complexity, and have unpredictable performance if generalized, and moving in the direction of encouraging the use of abstract AnyCollection values instead of concrete Arrays, that would free us to make covariant conversions cheaper by wrapping instead of eagerly mapping the array representation.
> 
> -Joe
>