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

Evolution Pitches
10

Before deciding how to divide the proposals, I would like to discuss the most important ones for now.

It is a change in the definition of what a protocol is and various changes that accompany it.
But with that said, it's hard for me to explain what a protocol is.

Therefore, I would like to put this on the back burner and explain how I would like to change the definition of the protocol.

First, the current protocol positions an associated type as something that conforming data types should define within it.
for example,

protocol P {
    associatedtype T
}

struct S: P {
    typealias T = Int // associated type T is defined here
}

I think this is where it gets really tricky.
I want to change it to:

protocol P<T> { }

struct S: P<T: Int> { }

It turns an associated type into a parameter of a protocol call.
When calling, describe the parameters with the parameter label.
See here for reasons to do this.

The above example simply shows what the format looks like when the data type conforms to the protocol.
A slightly more complex example, if the generic data type conforms to this protocol, could be written as:

struct S<T>: P<T: T> { }

The formal argument of S can be set to the actual argument of P.

In the case of protocol inheritance, it is written as follows.

protocol P1<T1> { }
protocol P2<T2> { }

protocol P3<T1, T2>: P1<T1: T1>, P2<T2: T2> { }

In the examples so far, the associated type has no type constraint, but it can of course.

protocol P1<T1: Equatable> { }

protocol P2<T2: Comparable>: P1<T1: T2> { }

It's a very rough explanation, but doesn't it look cleaner and easier to understand when the syntax changes like this?

This syntax eliminates the need to write a generic where clause, at least in protocol and data type definitions.

Wouldn't the internals of the compiler be cleaner and easier to understand?

I have more ideas for the protocol, but I'll take a break here.

2 Likes