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

Howard Lovatt howard.lovatt at gmail.com
Wed Jan 13 23:07:18 CST 2016


@Douglas,

Sure you can use SequenceType and constrain its associated types in where
clauses. But it is hard work :(. When you write your own stuff you end up
writing the equivalent of AnySequence and AnyGenerator as well, also hard
work.

I am proposing something that reduces programmer burden and strikes a
different balance,

 -- Howard.

On 14 January 2016 at 15:38, Douglas Gregor <dgregor at apple.com> wrote:

>
>
> Sent from my iPhone
>
> On Jan 13, 2016, at 5:05 PM, Howard Lovatt via swift-evolution <
> swift-evolution at swift.org> 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.
>
>
> In case you hadn't noticed, Swift provides a basic form of covariance for
> the collections in the standard library... And it does so without the need
> for runtime checking, because value semantics allow safe mutation and
> collection covariance.
>
>   - Doug
>
>
>
> 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.
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> 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/20160114/83acb011/attachment.html>


More information about the swift-evolution mailing list