[swift-evolution] Make generics covariant and add generics to protocols

David Waite david at alkaline-solutions.com
Wed Jan 13 17:13:22 CST 2016


> On Jan 13, 2016, at 4:02 PM, Austin Zheng via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hi Howard,
> 
> Making generics covariant by default would add even more of a burden to users. They would need to check the type property of a generic object any time they wanted to mutate that generic object or risk their program terminating.
> 
> I don't think the fact that array accesses are checked at runtime is a good example:
> 
> 1. The Swift team has stated that subscripting into an array returns a non-optional at least in part because of performance issues. (Unfortunately, I think this was mentioned on the old Apple developer forums, which are now inaccessible, so don't take my word for it until someone with more insight says so one way or another :).
> 2. The fact that this specific aspect of Swift is checked at runtime doesn't provide insight as to whether or not another aspect of Swift should be compile-time or runtime-checked; it just indicates that there exists the possibility of some checks being done at runtime (and every mainstream statically typed language performs runtime checks to some extent, this isn't a novel conclusion).
> 3. Checking that an array access is in bounds is trivial from a conceptual standpoint. The index needs to be at least 0 and at most the length of the array - 1.
> 4. The length of a Swift array is not part of the type contract, whereas the type enclosed within a generic type is. Swift doesn't have fixed-length arrays.

One might even argue the array length check is a precondition rather than a dynamic behavior. A developer is forced not to rely upon the bounds checking behavior, because an out-of-bounds error crashes the application. “Code crashes” is not a useful dynamic behavior and probably should not be used as an example for other behavior except in limited “developer messed up” scenarios.

-DW

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160113/5a13c98c/attachment.html>


More information about the swift-evolution mailing list