[swift-evolution] Casting Bug Swift

[Austin Zheng]

That's a bold move. Is opt-in covariance/contravariance as an alternative, with performance caveats explicitly denoted, still off the table? Would the Any(X)Collection types be automatically covariant, like Array<T> is now, or would it work differently somehow?

Austin

> On Feb 25, 2016, at 11:12 AM, Joe Groff via swift-evolution <swift-evolution at swift.org> 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
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution