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

[Howard Lovatt]

@David,

You said "developer messed up" for runtime crashes. The developer messed up
when the compiler finds a problem also. Its the same thing; if the compiler
statically finds a problem or the runtime finds a problem, in both cases
the "developer messed up". The only difference is that one is found at
compile time and the other is found at runtime.

My own guide in order of importance is:

 1. Ideally it should be type safe, i.e. the error is found either by the
runtime of the compiler. Obviously some languages, C, Obj-C, C++, are not
type safe, and you can write great programs in all 3 and therefore you
can't say that type safe is mandatory. By extension calls in Swift to C
etc. are not type safe and there are many such calls in any realistic Swift
program, is this a problem? Not really.
 2. Ideally the compiler will catch errors. Ideally, because this saves on
testing. However if this burdens the programmer greatly you have to
consider is it worth while. Many people prefer dynamically typed languages
for exactly this reason, they find declaring types more trouble than it is
worth. IE they feel the extra time spent annotating with type information
is not paid back in terms of reduced testing. This 'explicitly typing is a
pain' meme is common these days and has resulted in languages like Swift
that infer the type.

Combining these 2 points leads me to conclude that you should stick with
type safety were you can, infer type were you can, and only annotate extra
type information if that annotation increases programmer productivity.

Hence the proposal: its type safe, it infers type when it can, and for the
stuff that isn't worth annotating for it runtime checks.

Does that explain my reasoning?

 -- Howard.

On 14 January 2016 at 10:13, David Waite <david at alkaline-solutions.com>
wrote:

>
> 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
>
>


-- 
  -- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160114/788e1ee8/attachment.html>