[swift-evolution] Generic types―covariance/contravariance

[Braeden Profile]

I did some experimenting, and I see that most variance situations are covered by the compiler.  Generic collections and wrappers, like Optional or Array, are acceptable with .map and .flatMap, but currently benefit from compiler magic to cast those types.  However, not all the standard library generic types are convertible because they don’t all carry (the right) .map or .flatMap.  Observe:

struct GenericType<T>
{
	let t: T
	init(_ t: T)
		{ self.t = t }
	
	func map<U>(by transform: (T) -> U) -> GenericType<U>
		{ return GenericType<U>(transform(t)) }
	func flatMap<U>(by transform: (T) -> U?) -> GenericType<U>?
		{ return transform(t).map { GenericType<U>($0) } }
}


// let g = something using `as` and variance (or compiler magic) to cast.
// let G = something without using `as` or variance to cast.

// "Upcasting" the wrapped type:  All should return successfully cast types, as an Int is always an Any.  Casting with `as` always makes sense here.

let a = Optional<Int>(0) as Optional<Any> // This compiler magic is used absolutely everywhere.
let A = Optional<Int>(0).map { $0 } as Optional<Any> // Acceptable.

let b = Array<Int>() as Array<Any> // This compiler magic sometimes uses NSArray unexpectedly.
let B = Array<Int>().map { $0 } as Array<Any> // Acceptable.

let c = GenericType<Int>(0) as? GenericType<Any> // Without compiler magic, requires `as?` and never succeeds.
let C = GenericType<Int>(0).map { $0 } as GenericType<Any> // Acceptable.


// "Downcasting" the wrapped type:  Returns `nil` if the cast fails (where the wrapped Any isn't an Int).  Casting with `as` usually makes sense.

let x = Optional<Any>(0) as? Optional<Int> // Returns Optional<Int>, not Optional<Int>?.  This is different from the other two's desired result.
let X = Optional<Any>(0).flatMap { $0 as? Int } // Using map would return Optional<Int>?.

struct SomeError: Error {  }
let y = Array<Any>([4, ""]) as? Array<Int>
let Y = try? Array<Any>([4, ""]).map { try ($0 as? Int) ?? { throw SomeError() }() } // I don't have any idea how to accomplish that well.  flatMap doesn't do the same thing as returning Array<Int>? if one element fails.

let z = GenericType<Any>(0) as? GenericType<Int> // Without compiler magic, always fails.
let Z = GenericType<Any>(0).flatMap { $0 as? Int } // Does every generic type really need to implement a `map` and `flatMap` for polymorphism to exist?


// * Ranges——a standard library type with some serious problems. * //

class Number: Comparable
{
	// Stores a double.  Implementation is hidden.
}

class RationalNumber: Number
	{ /* Extra functionality */ }

let rationalRange: Range<RationalNumber> = .init(1.0) ..< .init(2.0)
let numberRange: Range<Number> = rationalRange // There's no .map to fix this problem!

Obviously, there is some room for improvement in polymorphism among generic types.  Upcasting, I think, is always a trivial matter and could be supported.  Downcasting is less cut and dry, but would still make sense if we could improve the situation we have.  Having to use .map and .flatMap every time you want to polymorphize any generic type—besides the compiler’s babies—is a pain.  What do you guys think?

Whether or not we find some sort of improvement here, I still wonder how I could identify my generic type from a parent type:

let any: Any = GenericType<Int>

if let generic = any as? GenericType<Any> // Currently fails for any GenericType<Int>, GenericType<String>, etc.
	{ /* Do something with my generic type  */ }


> On Dec 10, 2016, at 9:18 AM, David Waite <david at alkaline-solutions.com> wrote:
> 
> I wouldn’t keep it that narrow - monadic types like Optional also benefit from variance:
> 
> func p(_ data:Any?) { 
>   if data != nil { 
>     data.map { print($0) }
>   } 
> } 
> var a:String? = "foo"
> p(a)
> // -> “foo"
> 
> 
> -DW
> 
>> On Dec 9, 2016, at 12:24 PM, Hooman Mehr via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> For the specific case of custom collections, I think it is worth providing a protocol as Doug noted before.
>> 
>> Quoting Doug Gregor (1/13/16, thread: "Make generics covariant and add generics to protocols”): 
>>> Swift’s value-semantic collections are covariant in their generic parameters, which we do through some fairly tight coupling between the compiler and standard library. From a theoretical standpoint, I’m very happy with the way value-semantic collections provide subtyping and mutation while maintaining soundness (== no runtime checks needed), and for me I would consider it “enough” if we were to formalize that compiler/collection type interaction with some kind of protocol so other collection types could opt in to subtyping, because I don’t think variance—as a language feature—carries its weight outside of the fairly narrow collection-subtyping cases.
>> (Emphasis mine) 
>> 
>> I also agree with Doug and you that variance does not carry its weight outside of collection-subtyping cases.
> 
> -DW

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