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

Wed Jan 13 22:48:32 CST 2016

@Developer,

I doubt you really mean:

"I’ll put it simply: I would rather have a language that allows me to write
a smaller class of safer programs than one that allows a larger class of
flat-out wrong ones."

I doubt what you say because if that were the case in Swift you would
manually check for overflow and use the &+ operator instead of the +
operator, because the + operator overflows with a runtime exception.

All practical programming languages and all programmers even when given the
choice, e.g. + or &+ in Swift, will make a pragmatic choice:

 1. Is that compile time check worth it?
 2. Is that runtime check worth it?
 3. Or should I just cover this with a test case?

Its all a matter of balance,

 -- Howard.

On 14 January 2016 at 12:09, Developer <devteam.codafi at gmail.com> wrote:

> I think this is missing the point of type safety.  Whether checking occurs
> at runtime or compile time is irrelevant.  What I want is a programming
> language whose well-typed programs “don’t go wrong” (in the Robin Milner
> sense), not one that allows me to discover its own definition for “wrong”.
> What you call type safety is really just deferring errors until runtime,
> which defeats the purpose of even having one in the first place in my
> opinion.  Java made a horrendous mistake in this case, regardless of how
> common is may be in actual programs, and I don’t think Swift needs to make
> the same.
>
> I’ll put it simply: I would rather have a language that allows me to write
> a smaller class of safer programs than one that allows a larger class of
> flat-out wrong ones.
>
> On Jan 13, 2016, at 8:05 PM, Howard Lovatt <howard.lovatt at gmail.com>
> wrote:
>
> @Robert,
>
> The behaviour you show for Java arrays is what I am proposing, but that
> isn't type unsafe. The type error is detected at runtime and is flagged
> with an ArrayStoreException. This is unlike C for example that would allow
> the store, at least with a cast,  and would put into the array the address
> of the string. Therefore neither the proposal or Java is type unsafe, both
> are type safe and both detect type errors at runtime.
>
> The question is whether protecting against this is worthwhile, not whether
> it can be protected against or not (it can be). Arrays are a good example,
> Swift takes the approach (like most languages) of checking the array size
> at runtime. But languages with dependent typing check the array size at
> compile time, i.e. a dependently typed language would detect this error:
>
> let array = [1]
> array[0] // 1, OK
> array[1] // Error not detected by compiler but detected at runtime
>
> because in such a language array would be typed as int array of size one,
> not int array of any size.
>
> So the real question is in a language like Java, how many times do you get
> ArrayStoreException? In my own code I have never seen an array store
> exception! Why? Because contravariant writes are very rare. If you were to
> protect against contravariant writes you would be complicating the language
> for no practical gain, which I think is a bad trade off.
>
> Hope this explains the reasoning,
>
>  -- Howard.
>
> On 14 January 2016 at 09:21, Developer <devteam.codafi at gmail.com> wrote:
>
>> It does indeed make the type system unsound in some cases.  You have
>> chosen one particular variance direction because it is convenient. A
>> classic counterexample is Java making Arrays covariant by default.  So this
>> works
>>
>> Integer[] arr = [2, 4, 6, 8, 10];
>> Object[] orr = arr;
>> orr[0] = "crash bang";
>>
>> And crashes at runtime.  For that, I must give this part of the proposal
>> a strong -1.  Any amount of type safety I have to give up in the name of
>> convenience is far too much.
>>
>> I am, however, a fan of generic protocols.  They seem like an orthogonal
>> concept given the first part here though.
>>
>> ~Robert Widmann
>>
>> 2016/01/13 17:03、Howard Lovatt via swift-evolution <
>> swift-evolution at swift.org> のメッセージ:
>>
>> @Thorsten,
>>
>> It doesn't make the type system unsound; the types are mostly checked at
>> compile time but some are runtime checked, either way the types are checked
>> and therefore the type system is sound. I have posted an example of array
>> runtime type checking in a previous response.
>>
>> You can annotate variance, but this generally adds a lot of clutter to
>> the code (see some typical Java code that uses generics you will see stuff
>> like ? extends Type everywhere). In other languages like Scala the
>> annotation is less visually intrusive, because they use shorter syntax and
>> because it is annotated at declaration site rather than use site, but it is
>> still there.
>>
>> I think Swift arrays are a good example of partially static and partially
>> runtime checked. The content is statically typed but the size is runtime
>> typed. Other languages do type both the content and the size (see Dependent
>> Typing on Wiki), however at some considerable burden on the programmer.
>>
>> Hope this explains the thought process,
>>
>>  -- Howard.
>>
>> On 13 January 2016 at 16:50, Thorsten Seitz <tseitz42 at icloud.com> wrote:
>>
>>> Strong -1 from me as well for making the type system unsound.
>>>
>>> > Am 13.01.2016 um 02:47 schrieb Howard Lovatt via swift-evolution <
>>> swift-evolution at swift.org>:
>>> >
>>> > Yes you can annotate for covariance, invariance, and contravariance,
>>> both Java and Scala, allow all three. The problem is that the code becomes
>>> splattered with variance annotations
>>>
>>> Ceylon uses a different approach which is variance annotations at the
>>> definition site.
>>> This restricts the possible usage of the type parameters to
>>> appropriately variant positions.
>>>
>>> This migt be a better way to deal with variance.
>>>
>>> -Thorsten
>>
>>
>>
>>
>> --
>>   -- Howard.
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
> --
>   -- Howard.
>
>
>

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