Major evolution of the type system, including protocol improvements, etc

Evolution Pitches
7

I'm not good at English, so I don't fully understand the contents of the link above.

But I think it's deeply related to some of my proposals.
The relevant parts are:

  • Improve generic data types.
  • Improve protocols and introduce a generic protocol.
  • Introduces incomplete data types and incomplete protocols.

Here is an overview of these.

An incomplete data type is simply a generic data type that is used without some of its type parameters.

For example, we have some generic data type with two type parameters.
When using this, of course you need to give the two type parameters some concrete type.
This is the act of generating a normal, complete data type.

Consider using one or more type parameters without specifying a specific type.
This is the act of generating an incomplete data type.

Constituents of generic data types will have properties and methods referencing type parameters to interfaces and implementations.
An incomplete data type cannot refer to a type parameter that has not been given a concrete type.
As a result, some interfaces are no longer available, and so are all implementations.
This is similar to the protocol with PAT in Swift today, an abstract type to refer to some complete data type.
I think it's quite convenient because it eliminates the need to create parameter-erased data types such as AnyKeyPath and PartialKeyPath one by one.
Using the incomplete data type requires a small syntactic change from using the generic data type.

struct S<T1, T2> {
    var t1: T1
    var t2: T2
    init(t1: T1, t2: T2) { ... }
}

// Complete data type

let s = S<T1: Int, T2: String>(t1: 0, t2: "foo")

// Incomplete data types

var s1: S<T1: Int> = s
s1.t1 = 1
// s1 does not have property t2.

var s2: S<T2: String> = s
s2.t2 = "bar"
// s2 does not have property t1.

Consider parameterizing protocol association types in the same way as generic data types.
The result is a generic protocol.
Incomplete protocols can be generated from generic protocols as well as generic data types.
The syntax for using the generic protocol is slightly different than the syntax for using the protocol with PAT.

// Current definition style

protocol P {
    associatedtype T1
    associatedtype T2
    var t1: T1 { get set }
    var t2: T2 { get set }
}

// New definition style
// This is the generic protocol.
// "<T1, T2>" is not a PAT definition, it is an associated type parameter definition.

protocol P<T1, T2> {
    var t1: T1 { get set }
    var t2: T2 { get set }
}

// Here we assume that S conforms to P.
let s = S<T1: Int, T2: String>(t1: 0, t2: "foo")

// Complete protocol

var p: P<T1: Int, T2: String> = s
p.t1 = 1
p.t2 = "bar"

// Incomplete protocols

var p1: P<T1: Int> = s
p1.t1 = 1
// p1 does not have property t2.

var p2: P<T2: String> = s
p2.t2 = "bar"
// p2 does not have property t1.

The example above is transitional, as I propose other changes to the protocol.

1 Like