[swift-evolution] Casting Bug Swift

[Howard Lovatt]

I think it would be a good idea to remove the covariance of Array since it
is compiler magic and that would clear the way for a more general solution.

On Friday, 26 February 2016, Radek Pietruszewski via swift-evolution <
swift-evolution at swift.org> 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?
> - 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 <javascript:;>>
> wrote:
> >
> >
> >> On Feb 25, 2016, at 9:07 AM, Jordan Rose via swift-evolution <
> swift-evolution at swift.org <javascript:;>> 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 <javascript:;>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>


-- 
-- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160226/20f53880/attachment.html>