Constrained Protocol Aliases

Hello, Swift community!

I'd like to start a discussion about a possibility of constrained protocol aliases. The declaration would look like this:

typealias BinaryProtocol = RandomAccessCollection & MutablCollection & RangeReplaceableCollection where Binary.Index == Int, Binary.Element == Bool

The syntax and semantics of this declaration are exactly the same as an analogous associatedtype declaration inside a protocol.
In the example above, the type BinaryProtocol represents a logical array of bits and is a generic-only protocol that is usable in any context where an integer-indexed mutable range-replaceable random-access collection is expected.
Now, it can be used in a very concise and elegant way:

public protocol BinaryInitializable {
  init<Binary>(binary: Binary) where Binary: BinaryProtocol
}

which would otherwise look very verbose and inelegant:

public protocol BinaryInitializable {
  init<Binary>(binary: Binary) where Binary: RandomAccessCollection & MutablCollection & RangeReplaceableCollection, Binary.Index == Int, Binary.Element == Bool
}

Considering that smaller sets of constraints could be aliased to their own protocol and then composited into more complex aliases, this feature would dramatically improve readability and maintainability of code that uses complex constraints, that currently leads to arcane mess:

struct Mirror {
  /// ...
  init<Subject, C where C : Collection, C.Indices : Collection, C.SubSequence : Collection, C.Indices.Index == C.Index, C.Indices.SubSequence == C.Indices, C.Iterator.Element == Mirror.Child, C.SubSequence.Index == C.Index, C.SubSequence.Indices : Collection, C.SubSequence.SubSequence == C.SubSequence, C.Indices.Iterator.Element == C.Index, C.SubSequence.Indices.Index == C.Index, C.SubSequence.Indices.SubSequence == C.SubSequence.Indices, C.SubSequence.Iterator.Element == Mirror.Child, C.SubSequence.Indices.Iterator.Element == C.Index>(_ subject: Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, ancestorRepresentation: Mirror.AncestorRepresentation = default)
  /// ...
}

/// A collection that is its own sub-sequence
typealias RecursivelySliceableCollection = Collection where
  RecursivelySliceableCollection.SubSequence: Collection,
  RecursivelySliceableCollection.SubSequence.Element == RecursivelySliceableCollection.Element
  RecursivelySliceableCollection.SubSequence.Indices == RecursivelySliceableCollection.Indices,
    RecursivelySliceableCollection.SubSequence.SubSequence == RecursivelySliceableCollection.SubSequence

/// A collection that is its own index collection
typealias RecursivelyIndexableCollection = Collection where
  RecursivelyIndexableCollection.Indices == RecursivelySliceableCollection,
  RecursivelyIndexableCollection.Indices.Index == RecursivelyIndexableCollection.Index,

struct Mirror {
  /// ...
  init<Subject, C: RecursivelySliceableCollection & RecursivelyIndexableCollection, where C.Element == Mirror.Child>(_ subject: Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, ancestorRepresentation: Mirror.AncestorRepresentation = default)
  /// ...
}

Even considering that the proposal SE-0157 (https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md) is going to make this specific use case a non-issue, the principle applies to all cases where there are commonly used complex constraints that don't necessarily involve recursive constraints.

Specializing Generic-Only Protocols For Non-Generic Use

An additional feature that would prove to be very useful would be to make a constrained protocol alias be a non-generic-only protocol if the constraints of the alias declaration specify a same-type requirement for all its associated types, while defaulted associated types would also count.
Example:

protocol Consumer {
  associatedtype Consumable
  mutating func consume(_ consumable: Consumable) throws
}

var consumer0: Consumer // error: Consumer is only usable in a generic context

typealias CharacterConsumer = Consumer where CharacterConsumer.Consumable == Character

var consumer1: CharacterConsumer // OK

The current workaround would be to declare a new protocol with protocol inheritance clauses and a where clause, but the major downside is that it introduces a completely new protocol that is not compatible with any context that expects the underlying protocols and their constraints.

Regards,
Gor Gyolchanyan.

Yes, `where` clause is welcome to typealises (including generic ones) and existentials in general. I would love to help on such proposal. I think David Hart is also interested in this one. (cc)

···

Am 21. August 2017 um 11:38:14, Gor Gyolchanyan via swift-evolution (swift-evolution@swift.org) schrieb:

Hello, Swift community!

I'd like to start a discussion about a possibility of constrained protocol aliases. The declaration would look like this:

typealias BinaryProtocol = RandomAccessCollection & MutablCollection & RangeReplaceableCollection where Binary.Index == Int, Binary.Element == Bool

The syntax and semantics of this declaration are exactly the same as an analogous associatedtype declaration inside a protocol.
In the example above, the type BinaryProtocol represents a logical array of bits and is a generic-only protocol that is usable in any context where an integer-indexed mutable range-replaceable random-access collection is expected.
Now, it can be used in a very concise and elegant way:

public protocol BinaryInitializable {
init<Binary>(binary: Binary) where Binary: BinaryProtocol
}

which would otherwise look very verbose and inelegant:

public protocol BinaryInitializable {
init<Binary>(binary: Binary) where Binary: RandomAccessCollection & MutablCollection & RangeReplaceableCollection, Binary.Index == Int, Binary.Element == Bool
}

Considering that smaller sets of constraints could be aliased to their own protocol and then composited into more complex aliases, this feature would dramatically improve readability and maintainability of code that uses complex constraints, that currently leads to arcane mess:

struct Mirror {
/// ...
init<Subject, C where C : Collection, C.Indices : Collection, C.SubSequence : Collection, C.Indices.Index == C.Index, C.Indices.SubSequence == C.Indices, C.Iterator.Element == Mirror.Child, C.SubSequence.Index == C.Index, C.SubSequence.Indices : Collection, C.SubSequence.SubSequence == C.SubSequence, C.Indices.Iterator.Element == C.Index, C.SubSequence.Indices.Index == C.Index, C.SubSequence.Indices.SubSequence == C.SubSequence.Indices, C.SubSequence.Iterator.Element == Mirror.Child, C.SubSequence.Indices.Iterator.Element == C.Index>(_ subject: Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}

/// A collection that is its own sub-sequence
typealias RecursivelySliceableCollection = Collection where
RecursivelySliceableCollection.SubSequence: Collection,
RecursivelySliceableCollection.SubSequence.Element == RecursivelySliceableCollection.Element
RecursivelySliceableCollection.SubSequence.Indices == RecursivelySliceableCollection.Indices,
RecursivelySliceableCollection.SubSequence.SubSequence == RecursivelySliceableCollection.SubSequence

/// A collection that is its own index collection
typealias RecursivelyIndexableCollection = Collection where
RecursivelyIndexableCollection.Indices == RecursivelySliceableCollection,
RecursivelyIndexableCollection.Indices.Index == RecursivelyIndexableCollection.Index,

struct Mirror {
/// ...
init<Subject, C: RecursivelySliceableCollection & RecursivelyIndexableCollection, where C.Element == Mirror.Child>(_ subject: Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}

Even considering that the proposal SE-0157 (https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md) is going to make this specific use case a non-issue, the principle applies to all cases where there are commonly used complex constraints that don't necessarily involve recursive constraints.

Specializing Generic-Only Protocols For Non-Generic Use

An additional feature that would prove to be very useful would be to make a constrained protocol alias be a non-generic-only protocol if the constraints of the alias declaration specify a same-type requirement for all its associated types, while defaulted associated types would also count.
Example:

protocol Consumer {
associatedtype Consumable
mutating func consume(_ consumable: Consumable) throws
}

var consumer0: Consumer // error: Consumer is only usable in a generic context

typealias CharacterConsumer = Consumer where CharacterConsumer.Consumable == Character

var consumer1: CharacterConsumer // OK

The current workaround would be to declare a new protocol with protocol inheritance clauses and a where clause, but the major downside is that it introduces a completely new protocol that is not compatible with any context that expects the underlying protocols and their constraints.

Regards,
Gor Gyolchanyan.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I'm not very familiar with the Swift compiler codebase and it would take me more time to implement this than someone that has already contributed before. Considering that since Swift 5 proposals are required to include a pull request with an implementation, it would be much faster if someone with better knowledge of the compiler codebase would help me with the implementation, so a formal proposal could be made.

So... If someone wants to pitch in and help implement this, I'd be very grateful! :slightly_smiling_face:

I do want to get around to study the compiler's code inside-and-out, but that's an asynchronous process.

···

On Aug 21, 2017, at 12:41 PM, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:

Yes, `where` clause is welcome to typealises (including generic ones) and existentials in general. I would love to help on such proposal. I think David Hart is also interested in this one. (cc)

Am 21. August 2017 um 11:38:14, Gor Gyolchanyan via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

Hello, Swift community!

I'd like to start a discussion about a possibility of constrained protocol aliases. The declaration would look like this:

typealias BinaryProtocol = RandomAccessCollection & MutablCollection & RangeReplaceableCollection where Binary.Index == Int, Binary.Element == Bool

The syntax and semantics of this declaration are exactly the same as an analogous associatedtype declaration inside a protocol.
In the example above, the type BinaryProtocol represents a logical array of bits and is a generic-only protocol that is usable in any context where an integer-indexed mutable range-replaceable random-access collection is expected.
Now, it can be used in a very concise and elegant way:

public protocol BinaryInitializable {
init<Binary>(binary: Binary) where Binary: BinaryProtocol
}

which would otherwise look very verbose and inelegant:

public protocol BinaryInitializable {
init<Binary>(binary: Binary) where Binary: RandomAccessCollection & MutablCollection & RangeReplaceableCollection, Binary.Index == Int, Binary.Element == Bool
}

Considering that smaller sets of constraints could be aliased to their own protocol and then composited into more complex aliases, this feature would dramatically improve readability and maintainability of code that uses complex constraints, that currently leads to arcane mess:

struct Mirror {
/// ...
init<Subject, C where C : Collection, C.Indices : Collection, C.SubSequence : Collection, C.Indices.Index == C.Index, C.Indices.SubSequence == C.Indices, C.Iterator.Element == Mirror.Child, C.SubSequence.Index == C.Index, C.SubSequence.Indices : Collection, C.SubSequence.SubSequence == C.SubSequence, C.Indices.Iterator.Element == C.Index, C.SubSequence.Indices.Index == C.Index, C.SubSequence.Indices.SubSequence == C.SubSequence.Indices, C.SubSequence.Iterator.Element == Mirror.Child, C.SubSequence.Indices.Iterator.Element == C.Index>(_ subject: Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}

/// A collection that is its own sub-sequence
typealias RecursivelySliceableCollection = Collection where
RecursivelySliceableCollection.SubSequence: Collection,
RecursivelySliceableCollection.SubSequence.Element == RecursivelySliceableCollection.Element
RecursivelySliceableCollection.SubSequence.Indices == RecursivelySliceableCollection.Indices,
RecursivelySliceableCollection.SubSequence.SubSequence == RecursivelySliceableCollection.SubSequence

/// A collection that is its own index collection
typealias RecursivelyIndexableCollection = Collection where
RecursivelyIndexableCollection.Indices == RecursivelySliceableCollection,
RecursivelyIndexableCollection.Indices.Index == RecursivelyIndexableCollection.Index,

struct Mirror {
/// ...
init<Subject, C: RecursivelySliceableCollection & RecursivelyIndexableCollection, where C.Element == Mirror.Child>(_ subject: Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}

Even considering that the proposal SE-0157 (https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md) is going to make this specific use case a non-issue, the principle applies to all cases where there are commonly used complex constraints that don't necessarily involve recursive constraints.

Specializing Generic-Only Protocols For Non-Generic Use

An additional feature that would prove to be very useful would be to make a constrained protocol alias be a non-generic-only protocol if the constraints of the alias declaration specify a same-type requirement for all its associated types, while defaulted associated types would also count.
Example:

protocol Consumer {
associatedtype Consumable
mutating func consume(_ consumable: Consumable) throws
}

var consumer0: Consumer // error: Consumer is only usable in a generic context

typealias CharacterConsumer = Consumer where CharacterConsumer.Consumable == Character

var consumer1: CharacterConsumer // OK

The current workaround would be to declare a new protocol with protocol inheritance clauses and a where clause, but the major downside is that it introduces a completely new protocol that is not compatible with any context that expects the underlying protocols and their constraints.

Regards,
Gor Gyolchanyan.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Yes, `where` clause is welcome to typealises (including generic ones) and existentials in general. I would love to help on such proposal. I think David Hart is also interested in this one. (cc)

Yes, this basically seems like Generalized Existentials to me and is mentioned in the Generics Manifesto <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md>. It’s a feature I hold very dear but:

It’s a very difficult feature to implement and I think Doug Gregor is the only/best person to do it
I think its pretty much out of scope for Swift 5 (it’s not required for ABI Stability)

As a result, I’d be very surprised if this topic got any discussion or implementation time during the Swift 5 timeframe.

···

On 21 Aug 2017, at 11:41, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:
Am 21. August 2017 um 11:38:14, Gor Gyolchanyan via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

Hello, Swift community!

I'd like to start a discussion about a possibility of constrained protocol aliases. The declaration would look like this:

typealias BinaryProtocol = RandomAccessCollection & MutablCollection & RangeReplaceableCollection where Binary.Index == Int, Binary.Element == Bool

The syntax and semantics of this declaration are exactly the same as an analogous associatedtype declaration inside a protocol.
In the example above, the type BinaryProtocol represents a logical array of bits and is a generic-only protocol that is usable in any context where an integer-indexed mutable range-replaceable random-access collection is expected.
Now, it can be used in a very concise and elegant way:

public protocol BinaryInitializable {
init<Binary>(binary: Binary) where Binary: BinaryProtocol
}

which would otherwise look very verbose and inelegant:

public protocol BinaryInitializable {
init<Binary>(binary: Binary) where Binary: RandomAccessCollection & MutablCollection & RangeReplaceableCollection, Binary.Index == Int, Binary.Element == Bool
}

Considering that smaller sets of constraints could be aliased to their own protocol and then composited into more complex aliases, this feature would dramatically improve readability and maintainability of code that uses complex constraints, that currently leads to arcane mess:

struct Mirror {
/// ...
init<Subject, C where C : Collection, C.Indices : Collection, C.SubSequence : Collection, C.Indices.Index == C.Index, C.Indices.SubSequence == C.Indices, C.Iterator.Element == Mirror.Child, C.SubSequence.Index == C.Index, C.SubSequence.Indices : Collection, C.SubSequence.SubSequence == C.SubSequence, C.Indices.Iterator.Element == C.Index, C.SubSequence.Indices.Index == C.Index, C.SubSequence.Indices.SubSequence == C.SubSequence.Indices, C.SubSequence.Iterator.Element == Mirror.Child, C.SubSequence.Indices.Iterator.Element == C.Index>(_ subject: Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}

/// A collection that is its own sub-sequence
typealias RecursivelySliceableCollection = Collection where
RecursivelySliceableCollection.SubSequence: Collection,
RecursivelySliceableCollection.SubSequence.Element == RecursivelySliceableCollection.Element
RecursivelySliceableCollection.SubSequence.Indices == RecursivelySliceableCollection.Indices,
RecursivelySliceableCollection.SubSequence.SubSequence == RecursivelySliceableCollection.SubSequence

/// A collection that is its own index collection
typealias RecursivelyIndexableCollection = Collection where
RecursivelyIndexableCollection.Indices == RecursivelySliceableCollection,
RecursivelyIndexableCollection.Indices.Index == RecursivelyIndexableCollection.Index,

struct Mirror {
/// ...
init<Subject, C: RecursivelySliceableCollection & RecursivelyIndexableCollection, where C.Element == Mirror.Child>(_ subject: Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}

Even considering that the proposal SE-0157 (https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md) is going to make this specific use case a non-issue, the principle applies to all cases where there are commonly used complex constraints that don't necessarily involve recursive constraints.

Specializing Generic-Only Protocols For Non-Generic Use

An additional feature that would prove to be very useful would be to make a constrained protocol alias be a non-generic-only protocol if the constraints of the alias declaration specify a same-type requirement for all its associated types, while defaulted associated types would also count.
Example:

protocol Consumer {
associatedtype Consumable
mutating func consume(_ consumable: Consumable) throws
}

var consumer0: Consumer // error: Consumer is only usable in a generic context

typealias CharacterConsumer = Consumer where CharacterConsumer.Consumable == Character

var consumer1: CharacterConsumer // OK

The current workaround would be to declare a new protocol with protocol inheritance clauses and a where clause, but the major downside is that it introduces a completely new protocol that is not compatible with any context that expects the underlying protocols and their constraints.

Regards,
Gor Gyolchanyan.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

It’s part of Generalized Existentials, but does not make it complete. I think it would be worth adding more and more functionality to existentials every year. We started first with reshaping the syntax. This year we added support for classes. I think next year would be good to have where clause support for typealiases.

I understand the complexity of that particular feature, and it’s a no-go for me to help on the implementation, but I’m willing to drive the discussion and the proposal forward with other co-authors. :slight_smile:

Hasn’t it been said that the implementation must be at least a *proof-of-concept* if the complexity is very high?

And my second question is: Wouldn’t the existence of this feature reshape some parts of the standard library, isn’t that affecting some major goals of Swift 5?

It would be nice if someone from the core team can clarify if the where clause is out of scope for Swift 5 or not.

Am 21. August 2017 um 12:51:48, David Hart (david@hartbit.com) schrieb:

···

On 21 Aug 2017, at 11:41, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:

Yes, `where` clause is welcome to typealises (including generic ones) and existentials in general. I would love to help on such proposal. I think David Hart is also interested in this one. (cc)

Yes, this basically seems like Generalized Existentials to me and is mentioned in the Generics Manifesto. It’s a feature I hold very dear but:

It’s a very difficult feature to implement and I think Doug Gregor is the only/best person to do it
I think its pretty much out of scope for Swift 5 (it’s not required for ABI Stability)

As a result, I’d be very surprised if this topic got any discussion or implementation time during the Swift 5 timeframe.
Am 21. August 2017 um 11:38:14, Gor Gyolchanyan via swift-evolution (swift-evolution@swift.org) schrieb:

Hello, Swift community!

I'd like to start a discussion about a possibility of constrained protocol aliases. The declaration would look like this:

typealias BinaryProtocol = RandomAccessCollection & MutablCollection & RangeReplaceableCollection where Binary.Index == Int, Binary.Element == Bool

The syntax and semantics of this declaration are exactly the same as an analogous associatedtype declaration inside a protocol.
In the example above, the type BinaryProtocol represents a logical array of bits and is a generic-only protocol that is usable in any context where an integer-indexed mutable range-replaceable random-access collection is expected.
Now, it can be used in a very concise and elegant way:

public protocol BinaryInitializable {
init<Binary>(binary: Binary) where Binary: BinaryProtocol
}

which would otherwise look very verbose and inelegant:

public protocol BinaryInitializable {
init<Binary>(binary: Binary) where Binary: RandomAccessCollection & MutablCollection & RangeReplaceableCollection, Binary.Index == Int, Binary.Element == Bool
}

Considering that smaller sets of constraints could be aliased to their own protocol and then composited into more complex aliases, this feature would dramatically improve readability and maintainability of code that uses complex constraints, that currently leads to arcane mess:

struct Mirror {
/// ...
init<Subject, C where C : Collection, C.Indices : Collection, C.SubSequence : Collection, C.Indices.Index == C.Index, C.Indices.SubSequence == C.Indices, C.Iterator.Element == Mirror.Child, C.SubSequence.Index == C.Index, C.SubSequence.Indices : Collection, C.SubSequence.SubSequence == C.SubSequence, C.Indices.Iterator.Element == C.Index, C.SubSequence.Indices.Index == C.Index, C.SubSequence.Indices.SubSequence == C.SubSequence.Indices, C.SubSequence.Iterator.Element == Mirror.Child, C.SubSequence.Indices.Iterator.Element == C.Index>(_ subject: Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}

/// A collection that is its own sub-sequence
typealias RecursivelySliceableCollection = Collection where
RecursivelySliceableCollection.SubSequence: Collection,
RecursivelySliceableCollection.SubSequence.Element == RecursivelySliceableCollection.Element
RecursivelySliceableCollection.SubSequence.Indices == RecursivelySliceableCollection.Indices,
RecursivelySliceableCollection.SubSequence.SubSequence == RecursivelySliceableCollection.SubSequence

/// A collection that is its own index collection
typealias RecursivelyIndexableCollection = Collection where
RecursivelyIndexableCollection.Indices == RecursivelySliceableCollection,
RecursivelyIndexableCollection.Indices.Index == RecursivelyIndexableCollection.Index,

struct Mirror {
/// ...
init<Subject, C: RecursivelySliceableCollection & RecursivelyIndexableCollection, where C.Element == Mirror.Child>(_ subject: Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}

Even considering that the proposal SE-0157 (https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md) is going to make this specific use case a non-issue, the principle applies to all cases where there are commonly used complex constraints that don't necessarily involve recursive constraints.

Specializing Generic-Only Protocols For Non-Generic Use

An additional feature that would prove to be very useful would be to make a constrained protocol alias be a non-generic-only protocol if the constraints of the alias declaration specify a same-type requirement for all its associated types, while defaulted associated types would also count.
Example:

protocol Consumer {
associatedtype Consumable
mutating func consume(_ consumable: Consumable) throws
}

var consumer0: Consumer // error: Consumer is only usable in a generic context

typealias CharacterConsumer = Consumer where CharacterConsumer.Consumable == Character

var consumer1: CharacterConsumer // OK

The current workaround would be to declare a new protocol with protocol inheritance clauses and a where clause, but the major downside is that it introduces a completely new protocol that is not compatible with any context that expects the underlying protocols and their constraints.

Regards,
Gor Gyolchanyan.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

If anyone is thinking about spending time on this topic I recommend beginning by reviewing the prior work that was done by Austin Zheng. He has a proposal draft for enhanced existential that is very thorough. Even if you're not planning to propose everything that's included in his draft it would be a good idea to be familiar with it. Here's the link: https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md.

···

Sent from my iPad

On Aug 21, 2017, at 6:36 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

It’s part of Generalized Existentials, but does not make it complete. I think it would be worth adding more and more functionality to existentials every year. We started first with reshaping the syntax. This year we added support for classes. I think next year would be good to have where clause support for typealiases.

I understand the complexity of that particular feature, and it’s a no-go for me to help on the implementation, but I’m willing to drive the discussion and the proposal forward with other co-authors. :slight_smile:

Hasn’t it been said that the implementation must be at least a *proof-of-concept* if the complexity is very high?

And my second question is: Wouldn’t the existence of this feature reshape some parts of the standard library, isn’t that affecting some major goals of Swift 5?

It would be nice if someone from the core team can clarify if the where clause is out of scope for Swift 5 or not.

Am 21. August 2017 um 12:51:48, David Hart (david@hartbit.com) schrieb:

On 21 Aug 2017, at 11:41, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:

Yes, `where` clause is welcome to typealises (including generic ones) and existentials in general. I would love to help on such proposal. I think David Hart is also interested in this one. (cc)

Yes, this basically seems like Generalized Existentials to me and is mentioned in the Generics Manifesto. It’s a feature I hold very dear but:

It’s a very difficult feature to implement and I think Doug Gregor is the only/best person to do it
I think its pretty much out of scope for Swift 5 (it’s not required for ABI Stability)

As a result, I’d be very surprised if this topic got any discussion or implementation time during the Swift 5 timeframe.

Am 21. August 2017 um 11:38:14, Gor Gyolchanyan via swift-evolution (swift-evolution@swift.org) schrieb:

Hello, Swift community!

I'd like to start a discussion about a possibility of constrained protocol aliases. The declaration would look like this:

typealias BinaryProtocol = RandomAccessCollection & MutablCollection & RangeReplaceableCollection where Binary.Index == Int, Binary.Element == Bool

The syntax and semantics of this declaration are exactly the same as an analogous associatedtype declaration inside a protocol.
In the example above, the type BinaryProtocol represents a logical array of bits and is a generic-only protocol that is usable in any context where an integer-indexed mutable range-replaceable random-access collection is expected.
Now, it can be used in a very concise and elegant way:

public protocol BinaryInitializable {
init<Binary>(binary: Binary) where Binary: BinaryProtocol
}

which would otherwise look very verbose and inelegant:

public protocol BinaryInitializable {
init<Binary>(binary: Binary) where Binary: RandomAccessCollection & MutablCollection & RangeReplaceableCollection, Binary.Index == Int, Binary.Element == Bool
}

Considering that smaller sets of constraints could be aliased to their own protocol and then composited into more complex aliases, this feature would dramatically improve readability and maintainability of code that uses complex constraints, that currently leads to arcane mess:

struct Mirror {
/// ...
init<Subject, C where C : Collection, C.Indices : Collection, C.SubSequence : Collection, C.Indices.Index == C.Index, C.Indices.SubSequence == C.Indices, C.Iterator.Element == Mirror.Child, C.SubSequence.Index == C.Index, C.SubSequence.Indices : Collection, C.SubSequence.SubSequence == C.SubSequence, C.Indices.Iterator.Element == C.Index, C.SubSequence.Indices.Index == C.Index, C.SubSequence.Indices.SubSequence == C.SubSequence.Indices, C.SubSequence.Iterator.Element == Mirror.Child, C.SubSequence.Indices.Iterator.Element == C.Index>(_ subject: Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}

/// A collection that is its own sub-sequence
typealias RecursivelySliceableCollection = Collection where
RecursivelySliceableCollection.SubSequence: Collection,
RecursivelySliceableCollection.SubSequence.Element == RecursivelySliceableCollection.Element
RecursivelySliceableCollection.SubSequence.Indices == RecursivelySliceableCollection.Indices,
RecursivelySliceableCollection.SubSequence.SubSequence == RecursivelySliceableCollection.SubSequence

/// A collection that is its own index collection
typealias RecursivelyIndexableCollection = Collection where
RecursivelyIndexableCollection.Indices == RecursivelySliceableCollection,
RecursivelyIndexableCollection.Indices.Index == RecursivelyIndexableCollection.Index,

struct Mirror {
/// ...
init<Subject, C: RecursivelySliceableCollection & RecursivelyIndexableCollection, where C.Element == Mirror.Child>(_ subject: Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}

Even considering that the proposal SE-0157 (https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md) is going to make this specific use case a non-issue, the principle applies to all cases where there are commonly used complex constraints that don't necessarily involve recursive constraints.

Specializing Generic-Only Protocols For Non-Generic Use

An additional feature that would prove to be very useful would be to make a constrained protocol alias be a non-generic-only protocol if the constraints of the alias declaration specify a same-type requirement for all its associated types, while defaulted associated types would also count.
Example:

protocol Consumer {
associatedtype Consumable
mutating func consume(_ consumable: Consumable) throws
}

var consumer0: Consumer // error: Consumer is only usable in a generic context

typealias CharacterConsumer = Consumer where CharacterConsumer.Consumable == Character

var consumer1: CharacterConsumer // OK

The current workaround would be to declare a new protocol with protocol inheritance clauses and a where clause, but the major downside is that it introduces a completely new protocol that is not compatible with any context that expects the underlying protocols and their constraints.

Regards,
Gor Gyolchanyan.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

It’s part of Generalized Existentials, but does not make it complete. I think it would be worth adding more and more functionality to existentials every year. We started first with reshaping the syntax. This year we added support for classes. I think next year would be good to have where clause support for typealiases.

I understand the complexity of that particular feature, and it’s a no-go for me to help on the implementation, but I’m willing to drive the discussion and the proposal forward with other co-authors. :slight_smile:

Hasn’t it been said that the implementation must be at least a *proof-of-concept* if the complexity is very high?

I’d love to have this feature. But I’m not sure even a partway proposal will get to review with the laser-focus on ABI Stability + Concurrency. I don’t want to spend time co-authoring a proposal if it is going to be out of scope anyway. Perhaps Doug (CC) can give us some ideas.

And my second question is: Wouldn’t the existence of this feature reshape some parts of the standard library, isn’t that affecting some major goals of Swift 5?

Yes. But that also true of many other language feature. But the Standard Library still needs to be set in stone at some point or another.

It would be nice if someone from the core team can clarify if the where clause is out of scope for Swift 5 or not.

Agreed.

···

On 21 Aug 2017, at 13:36, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:

Am 21. August 2017 um 12:51:48, David Hart (david@hartbit.com <mailto:david@hartbit.com>) schrieb:

On 21 Aug 2017, at 11:41, Adrian Zubarev <adrian.zubarev@devandartist.com <mailto:adrian.zubarev@devandartist.com>> wrote:

Yes, `where` clause is welcome to typealises (including generic ones) and existentials in general. I would love to help on such proposal. I think David Hart is also interested in this one. (cc)

Yes, this basically seems like Generalized Existentials to me and is mentioned in the Generics Manifesto <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md>. It’s a feature I hold very dear but:

It’s a very difficult feature to implement and I think Doug Gregor is the only/best person to do it
I think its pretty much out of scope for Swift 5 (it’s not required for ABI Stability)

As a result, I’d be very surprised if this topic got any discussion or implementation time during the Swift 5 timeframe.

Am 21. August 2017 um 11:38:14, Gor Gyolchanyan via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

Hello, Swift community!

I'd like to start a discussion about a possibility of constrained protocol aliases. The declaration would look like this:

typealias BinaryProtocol = RandomAccessCollection & MutablCollection & RangeReplaceableCollection where Binary.Index == Int, Binary.Element == Bool

The syntax and semantics of this declaration are exactly the same as an analogous associatedtype declaration inside a protocol.
In the example above, the type BinaryProtocol represents a logical array of bits and is a generic-only protocol that is usable in any context where an integer-indexed mutable range-replaceable random-access collection is expected.
Now, it can be used in a very concise and elegant way:

public protocol BinaryInitializable {
init<Binary>(binary: Binary) where Binary: BinaryProtocol
}

which would otherwise look very verbose and inelegant:

public protocol BinaryInitializable {
init<Binary>(binary: Binary) where Binary: RandomAccessCollection & MutablCollection & RangeReplaceableCollection, Binary.Index == Int, Binary.Element == Bool
}

Considering that smaller sets of constraints could be aliased to their own protocol and then composited into more complex aliases, this feature would dramatically improve readability and maintainability of code that uses complex constraints, that currently leads to arcane mess:

struct Mirror {
/// ...
init<Subject, C where C : Collection, C.Indices : Collection, C.SubSequence : Collection, C.Indices.Index == C.Index, C.Indices.SubSequence == C.Indices, C.Iterator.Element == Mirror.Child, C.SubSequence.Index == C.Index, C.SubSequence.Indices : Collection, C.SubSequence.SubSequence == C.SubSequence, C.Indices.Iterator.Element == C.Index, C.SubSequence.Indices.Index == C.Index, C.SubSequence.Indices.SubSequence == C.SubSequence.Indices, C.SubSequence.Iterator.Element == Mirror.Child, C.SubSequence.Indices.Iterator.Element == C.Index>(_ subject: Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}

/// A collection that is its own sub-sequence
typealias RecursivelySliceableCollection = Collection where
RecursivelySliceableCollection.SubSequence: Collection,
RecursivelySliceableCollection.SubSequence.Element == RecursivelySliceableCollection.Element
RecursivelySliceableCollection.SubSequence.Indices == RecursivelySliceableCollection.Indices,
RecursivelySliceableCollection.SubSequence.SubSequence == RecursivelySliceableCollection.SubSequence

/// A collection that is its own index collection
typealias RecursivelyIndexableCollection = Collection where
RecursivelyIndexableCollection.Indices == RecursivelySliceableCollection,
RecursivelyIndexableCollection.Indices.Index == RecursivelyIndexableCollection.Index,

struct Mirror {
/// ...
init<Subject, C: RecursivelySliceableCollection & RecursivelyIndexableCollection, where C.Element == Mirror.Child>(_ subject: Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}

Even considering that the proposal SE-0157 (https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md) is going to make this specific use case a non-issue, the principle applies to all cases where there are commonly used complex constraints that don't necessarily involve recursive constraints.

Specializing Generic-Only Protocols For Non-Generic Use

An additional feature that would prove to be very useful would be to make a constrained protocol alias be a non-generic-only protocol if the constraints of the alias declaration specify a same-type requirement for all its associated types, while defaulted associated types would also count.
Example:

protocol Consumer {
associatedtype Consumable
mutating func consume(_ consumable: Consumable) throws
}

var consumer0: Consumer // error: Consumer is only usable in a generic context

typealias CharacterConsumer = Consumer where CharacterConsumer.Consumable == Character

var consumer1: CharacterConsumer // OK

The current workaround would be to declare a new protocol with protocol inheritance clauses and a where clause, but the major downside is that it introduces a completely new protocol that is not compatible with any context that expects the underlying protocols and their constraints.

Regards,
Gor Gyolchanyan.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Hi Matthew thank you for remembering us about that draft. I’ll re-read it soon. At the a quick glance I noticed the extent use of the `where` clause. Wouldn’t make sense to simplify the main proposal and just focus on the `where` clause for typealises only? It’s already a complex feature on its own. Permitting the `where` clause in different places can sill be added later in the future.

Am 21. August 2017 um 15:10:34, Matthew Johnson (matthew@anandabits.com) schrieb:

If anyone is thinking about spending time on this topic I recommend beginning by reviewing the prior work that was done by Austin Zheng. He has a proposal draft for enhanced existential that is very thorough. Even if you're not planning to propose everything that's included in his draft it would be a good idea to be familiar with it. Here's the link: https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md.

···

Sent from my iPad

On Aug 21, 2017, at 6:36 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

It’s part of Generalized Existentials, but does not make it complete. I think it would be worth adding more and more functionality to existentials every year. We started first with reshaping the syntax. This year we added support for classes. I think next year would be good to have where clause support for typealiases.

I understand the complexity of that particular feature, and it’s a no-go for me to help on the implementation, but I’m willing to drive the discussion and the proposal forward with other co-authors. :slight_smile:

Hasn’t it been said that the implementation must be at least a *proof-of-concept* if the complexity is very high?

And my second question is: Wouldn’t the existence of this feature reshape some parts of the standard library, isn’t that affecting some major goals of Swift 5?

It would be nice if someone from the core team can clarify if the where clause is out of scope for Swift 5 or not.

Am 21. August 2017 um 12:51:48, David Hart (david@hartbit.com) schrieb:

On 21 Aug 2017, at 11:41, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:

Yes, `where` clause is welcome to typealises (including generic ones) and existentials in general. I would love to help on such proposal. I think David Hart is also interested in this one. (cc)

Yes, this basically seems like Generalized Existentials to me and is mentioned in the Generics Manifesto. It’s a feature I hold very dear but:

It’s a very difficult feature to implement and I think Doug Gregor is the only/best person to do it
I think its pretty much out of scope for Swift 5 (it’s not required for ABI Stability)

As a result, I’d be very surprised if this topic got any discussion or implementation time during the Swift 5 timeframe.
Am 21. August 2017 um 11:38:14, Gor Gyolchanyan via swift-evolution (swift-evolution@swift.org) schrieb:

Hello, Swift community!

I'd like to start a discussion about a possibility of constrained protocol aliases. The declaration would look like this:

typealias BinaryProtocol = RandomAccessCollection & MutablCollection & RangeReplaceableCollection where Binary.Index == Int, Binary.Element == Bool

The syntax and semantics of this declaration are exactly the same as an analogous associatedtype declaration inside a protocol.
In the example above, the type BinaryProtocol represents a logical array of bits and is a generic-only protocol that is usable in any context where an integer-indexed mutable range-replaceable random-access collection is expected.
Now, it can be used in a very concise and elegant way:

public protocol BinaryInitializable {
init<Binary>(binary: Binary) where Binary: BinaryProtocol
}

which would otherwise look very verbose and inelegant:

public protocol BinaryInitializable {
init<Binary>(binary: Binary) where Binary: RandomAccessCollection & MutablCollection & RangeReplaceableCollection, Binary.Index == Int, Binary.Element == Bool
}

Considering that smaller sets of constraints could be aliased to their own protocol and then composited into more complex aliases, this feature would dramatically improve readability and maintainability of code that uses complex constraints, that currently leads to arcane mess:

struct Mirror {
/// ...
init<Subject, C where C : Collection, C.Indices : Collection, C.SubSequence : Collection, C.Indices.Index == C.Index, C.Indices.SubSequence == C.Indices, C.Iterator.Element == Mirror.Child, C.SubSequence.Index == C.Index, C.SubSequence.Indices : Collection, C.SubSequence.SubSequence == C.SubSequence, C.Indices.Iterator.Element == C.Index, C.SubSequence.Indices.Index == C.Index, C.SubSequence.Indices.SubSequence == C.SubSequence.Indices, C.SubSequence.Iterator.Element == Mirror.Child, C.SubSequence.Indices.Iterator.Element == C.Index>(_ subject: Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}

/// A collection that is its own sub-sequence
typealias RecursivelySliceableCollection = Collection where
RecursivelySliceableCollection.SubSequence: Collection,
RecursivelySliceableCollection.SubSequence.Element == RecursivelySliceableCollection.Element
RecursivelySliceableCollection.SubSequence.Indices == RecursivelySliceableCollection.Indices,
RecursivelySliceableCollection.SubSequence.SubSequence == RecursivelySliceableCollection.SubSequence

/// A collection that is its own index collection
typealias RecursivelyIndexableCollection = Collection where
RecursivelyIndexableCollection.Indices == RecursivelySliceableCollection,
RecursivelyIndexableCollection.Indices.Index == RecursivelyIndexableCollection.Index,

struct Mirror {
/// ...
init<Subject, C: RecursivelySliceableCollection & RecursivelyIndexableCollection, where C.Element == Mirror.Child>(_ subject: Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}

Even considering that the proposal SE-0157 (https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md) is going to make this specific use case a non-issue, the principle applies to all cases where there are commonly used complex constraints that don't necessarily involve recursive constraints.

Specializing Generic-Only Protocols For Non-Generic Use

An additional feature that would prove to be very useful would be to make a constrained protocol alias be a non-generic-only protocol if the constraints of the alias declaration specify a same-type requirement for all its associated types, while defaulted associated types would also count.
Example:

protocol Consumer {
associatedtype Consumable
mutating func consume(_ consumable: Consumable) throws
}

var consumer0: Consumer // error: Consumer is only usable in a generic context

typealias CharacterConsumer = Consumer where CharacterConsumer.Consumable == Character

var consumer1: CharacterConsumer // OK

The current workaround would be to declare a new protocol with protocol inheritance clauses and a where clause, but the major downside is that it introduces a completely new protocol that is not compatible with any context that expects the underlying protocols and their constraints.

Regards,
Gor Gyolchanyan.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

It’s part of Generalized Existentials, but does not make it complete. I think it would be worth adding more and more functionality to existentials every year. We started first with reshaping the syntax. This year we added support for classes. I think next year would be good to have where clause support for typealiases.

I understand the complexity of that particular feature, and it’s a no-go for me to help on the implementation, but I’m willing to drive the discussion and the proposal forward with other co-authors. :slight_smile:

Hasn’t it been said that the implementation must be at least a *proof-of-concept* if the complexity is very high?

I’d love to have this feature. But I’m not sure even a partway proposal will get to review with the laser-focus on ABI Stability + Concurrency. I don’t want to spend time co-authoring a proposal if it is going to be out of scope anyway. Perhaps Doug (CC) can give us some ideas.

The main issue is the implementation: it’s a nontrivial feature with impact on the AST, type checker, SIL, IR generation, type metadata, and runtime. On the other hand, it’s one of these features that’s 95% testable refactoring: one can plumb the notion of “generalized existential” through the whole compiler as a generalization of the existing existential types. The core abstraction needed to capture the requirements on the existential (GenericSignature) is already there in the compiler for generics, and much of the task is to generalize (as appropriate) and use that machinery for existentials.

It’s not an easy feature, but there are many capable people who could do it, and of course we’ll be happy to give guidance/review over on swift-dev if someone would like to work on it. The refactoring I mentioned could be developed on master (incrementally) as a general improvement to the compiler, so the implementation of the feature itself is a small, more syntactically-focused separate piece.

And my second question is: Wouldn’t the existence of this feature reshape some parts of the standard library, isn’t that affecting some major goals of Swift 5?

Yes. But that also true of many other language feature. But the Standard Library still needs to be set in stone at some point or another.

Generalized existentials would affect some parts of the standard library (e.g., they’d be a better way to implement AnyCollection et al), but generalized existentials are not a game-changer for the design.

It would be nice if someone from the core team can clarify if the where clause is out of scope for Swift 5 or not.

Agreed.

It’s not “out of scope”, but everything hinges on the implementation task.

  - Doug

···

On Aug 21, 2017, at 5:51 AM, David Hart <david@hartbit.com> wrote:

On 21 Aug 2017, at 13:36, Adrian Zubarev <adrian.zubarev@devandartist.com <mailto:adrian.zubarev@devandartist.com>> wrote:

Am 21. August 2017 um 12:51:48, David Hart (david@hartbit.com <mailto:david@hartbit.com>) schrieb:

On 21 Aug 2017, at 11:41, Adrian Zubarev <adrian.zubarev@devandartist.com <mailto:adrian.zubarev@devandartist.com>> wrote:

Yes, `where` clause is welcome to typealises (including generic ones) and existentials in general. I would love to help on such proposal. I think David Hart is also interested in this one. (cc)

Yes, this basically seems like Generalized Existentials to me and is mentioned in the Generics Manifesto <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md>. It’s a feature I hold very dear but:

It’s a very difficult feature to implement and I think Doug Gregor is the only/best person to do it
I think its pretty much out of scope for Swift 5 (it’s not required for ABI Stability)

As a result, I’d be very surprised if this topic got any discussion or implementation time during the Swift 5 timeframe.

Am 21. August 2017 um 11:38:14, Gor Gyolchanyan via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

Hello, Swift community!

I'd like to start a discussion about a possibility of constrained protocol aliases. The declaration would look like this:

typealias BinaryProtocol = RandomAccessCollection & MutablCollection & RangeReplaceableCollection where Binary.Index == Int, Binary.Element == Bool

The syntax and semantics of this declaration are exactly the same as an analogous associatedtype declaration inside a protocol.
In the example above, the type BinaryProtocol represents a logical array of bits and is a generic-only protocol that is usable in any context where an integer-indexed mutable range-replaceable random-access collection is expected.
Now, it can be used in a very concise and elegant way:

public protocol BinaryInitializable {
init<Binary>(binary: Binary) where Binary: BinaryProtocol
}

which would otherwise look very verbose and inelegant:

public protocol BinaryInitializable {
init<Binary>(binary: Binary) where Binary: RandomAccessCollection & MutablCollection & RangeReplaceableCollection, Binary.Index == Int, Binary.Element == Bool
}

Considering that smaller sets of constraints could be aliased to their own protocol and then composited into more complex aliases, this feature would dramatically improve readability and maintainability of code that uses complex constraints, that currently leads to arcane mess:

struct Mirror {
/// ...
init<Subject, C where C : Collection, C.Indices : Collection, C.SubSequence : Collection, C.Indices.Index == C.Index, C.Indices.SubSequence == C.Indices, C.Iterator.Element == Mirror.Child, C.SubSequence.Index == C.Index, C.SubSequence.Indices : Collection, C.SubSequence.SubSequence == C.SubSequence, C.Indices.Iterator.Element == C.Index, C.SubSequence.Indices.Index == C.Index, C.SubSequence.Indices.SubSequence == C.SubSequence.Indices, C.SubSequence.Iterator.Element == Mirror.Child, C.SubSequence.Indices.Iterator.Element == C.Index>(_ subject: Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}

/// A collection that is its own sub-sequence
typealias RecursivelySliceableCollection = Collection where
RecursivelySliceableCollection.SubSequence: Collection,
RecursivelySliceableCollection.SubSequence.Element == RecursivelySliceableCollection.Element
RecursivelySliceableCollection.SubSequence.Indices == RecursivelySliceableCollection.Indices,
RecursivelySliceableCollection.SubSequence.SubSequence == RecursivelySliceableCollection.SubSequence

/// A collection that is its own index collection
typealias RecursivelyIndexableCollection = Collection where
RecursivelyIndexableCollection.Indices == RecursivelySliceableCollection,
RecursivelyIndexableCollection.Indices.Index == RecursivelyIndexableCollection.Index,

struct Mirror {
/// ...
init<Subject, C: RecursivelySliceableCollection & RecursivelyIndexableCollection, where C.Element == Mirror.Child>(_ subject: Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}

Even considering that the proposal SE-0157 (https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md) is going to make this specific use case a non-issue, the principle applies to all cases where there are commonly used complex constraints that don't necessarily involve recursive constraints.

Specializing Generic-Only Protocols For Non-Generic Use

An additional feature that would prove to be very useful would be to make a constrained protocol alias be a non-generic-only protocol if the constraints of the alias declaration specify a same-type requirement for all its associated types, while defaulted associated types would also count.
Example:

protocol Consumer {
associatedtype Consumable
mutating func consume(_ consumable: Consumable) throws
}

var consumer0: Consumer // error: Consumer is only usable in a generic context

typealias CharacterConsumer = Consumer where CharacterConsumer.Consumable == Character

var consumer1: CharacterConsumer // OK

The current workaround would be to declare a new protocol with protocol inheritance clauses and a where clause, but the major downside is that it introduces a completely new protocol that is not compatible with any context that expects the underlying protocols and their constraints.

Regards,
Gor Gyolchanyan.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Hi Matthew thank you for remembering us about that draft. I’ll re-read it soon. At the a quick glance I noticed the extent use of the `where` clause. Wouldn’t make sense to simplify the main proposal and just focus on the `where` clause for typealises only? It’s already a complex feature on its own. Permitting the `where` clause in different places can sill be added later in the future.

At first glance, it looks to me like the typealias would need to refer to a generalized existential anyway and if we can do that through a typealias we should probably be able to do it directly as well. That said, if it simplifies the implementation in some way it might make sense as a first step. Whether or not that would be the case is something I can’t speak to with any confidence.

···

On Aug 21, 2017, at 10:31 AM, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:

Am 21. August 2017 um 15:10:34, Matthew Johnson (matthew@anandabits.com <mailto:matthew@anandabits.com>) schrieb:

If anyone is thinking about spending time on this topic I recommend beginning by reviewing the prior work that was done by Austin Zheng. He has a proposal draft for enhanced existential that is very thorough. Even if you're not planning to propose everything that's included in his draft it would be a good idea to be familiar with it. Here's the link: https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md.

Sent from my iPad

On Aug 21, 2017, at 6:36 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

It’s part of Generalized Existentials, but does not make it complete. I think it would be worth adding more and more functionality to existentials every year. We started first with reshaping the syntax. This year we added support for classes. I think next year would be good to have where clause support for typealiases.

I understand the complexity of that particular feature, and it’s a no-go for me to help on the implementation, but I’m willing to drive the discussion and the proposal forward with other co-authors. :slight_smile:

Hasn’t it been said that the implementation must be at least a *proof-of-concept* if the complexity is very high?

And my second question is: Wouldn’t the existence of this feature reshape some parts of the standard library, isn’t that affecting some major goals of Swift 5?

It would be nice if someone from the core team can clarify if the where clause is out of scope for Swift 5 or not.

Am 21. August 2017 um 12:51:48, David Hart (david@hartbit.com <mailto:david@hartbit.com>) schrieb:

On 21 Aug 2017, at 11:41, Adrian Zubarev <adrian.zubarev@devandartist.com <mailto:adrian.zubarev@devandartist.com>> wrote:

Yes, `where` clause is welcome to typealises (including generic ones) and existentials in general. I would love to help on such proposal. I think David Hart is also interested in this one. (cc)

Yes, this basically seems like Generalized Existentials to me and is mentioned in the Generics Manifesto <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md>. It’s a feature I hold very dear but:

It’s a very difficult feature to implement and I think Doug Gregor is the only/best person to do it
I think its pretty much out of scope for Swift 5 (it’s not required for ABI Stability)

As a result, I’d be very surprised if this topic got any discussion or implementation time during the Swift 5 timeframe.

Am 21. August 2017 um 11:38:14, Gor Gyolchanyan via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

Hello, Swift community!

I'd like to start a discussion about a possibility of constrained protocol aliases. The declaration would look like this:

typealias BinaryProtocol = RandomAccessCollection & MutablCollection & RangeReplaceableCollection where Binary.Index == Int, Binary.Element == Bool

The syntax and semantics of this declaration are exactly the same as an analogous associatedtype declaration inside a protocol.
In the example above, the type BinaryProtocol represents a logical array of bits and is a generic-only protocol that is usable in any context where an integer-indexed mutable range-replaceable random-access collection is expected.
Now, it can be used in a very concise and elegant way:

public protocol BinaryInitializable {
init<Binary>(binary: Binary) where Binary: BinaryProtocol
}

which would otherwise look very verbose and inelegant:

public protocol BinaryInitializable {
init<Binary>(binary: Binary) where Binary: RandomAccessCollection & MutablCollection & RangeReplaceableCollection, Binary.Index == Int, Binary.Element == Bool
}

Considering that smaller sets of constraints could be aliased to their own protocol and then composited into more complex aliases, this feature would dramatically improve readability and maintainability of code that uses complex constraints, that currently leads to arcane mess:

struct Mirror {
/// ...
init<Subject, C where C : Collection, C.Indices : Collection, C.SubSequence : Collection, C.Indices.Index == C.Index, C.Indices.SubSequence == C.Indices, C.Iterator.Element == Mirror.Child, C.SubSequence.Index == C.Index, C.SubSequence.Indices : Collection, C.SubSequence.SubSequence == C.SubSequence, C.Indices.Iterator.Element == C.Index, C.SubSequence.Indices.Index == C.Index, C.SubSequence.Indices.SubSequence == C.SubSequence.Indices, C.SubSequence.Iterator.Element == Mirror.Child, C.SubSequence.Indices.Iterator.Element == C.Index>(_ subject: Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}

/// A collection that is its own sub-sequence
typealias RecursivelySliceableCollection = Collection where
RecursivelySliceableCollection.SubSequence: Collection,
RecursivelySliceableCollection.SubSequence.Element == RecursivelySliceableCollection.Element
RecursivelySliceableCollection.SubSequence.Indices == RecursivelySliceableCollection.Indices,
RecursivelySliceableCollection.SubSequence.SubSequence == RecursivelySliceableCollection.SubSequence

/// A collection that is its own index collection
typealias RecursivelyIndexableCollection = Collection where
RecursivelyIndexableCollection.Indices == RecursivelySliceableCollection,
RecursivelyIndexableCollection.Indices.Index == RecursivelyIndexableCollection.Index,

struct Mirror {
/// ...
init<Subject, C: RecursivelySliceableCollection & RecursivelyIndexableCollection, where C.Element == Mirror.Child>(_ subject: Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}

Even considering that the proposal SE-0157 (https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md) is going to make this specific use case a non-issue, the principle applies to all cases where there are commonly used complex constraints that don't necessarily involve recursive constraints.

Specializing Generic-Only Protocols For Non-Generic Use

An additional feature that would prove to be very useful would be to make a constrained protocol alias be a non-generic-only protocol if the constraints of the alias declaration specify a same-type requirement for all its associated types, while defaulted associated types would also count.
Example:

protocol Consumer {
associatedtype Consumable
mutating func consume(_ consumable: Consumable) throws
}

var consumer0: Consumer // error: Consumer is only usable in a generic context

typealias CharacterConsumer = Consumer where CharacterConsumer.Consumable == Character

var consumer1: CharacterConsumer // OK

The current workaround would be to declare a new protocol with protocol inheritance clauses and a where clause, but the major downside is that it introduces a completely new protocol that is not compatible with any context that expects the underlying protocols and their constraints.

Regards,
Gor Gyolchanyan.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

It’s part of Generalized Existentials, but does not make it complete. I
think it would be worth adding more and more functionality to existentials
every year. We started first with reshaping the syntax. This year we added
support for classes. I think next year would be good to have where clause
support for typealiases.

I understand the complexity of that particular feature, and it’s a no-go
for me to help on the implementation, but I’m willing to drive the
discussion and the proposal forward with other co-authors. :slight_smile:

Hasn’t it been said that the implementation must be at least a
*proof-of-concept* if the complexity is very high?

I’d love to have this feature. But I’m not sure even a partway proposal
will get to review with the laser-focus on ABI Stability + Concurrency. I
don’t want to spend time co-authoring a proposal if it is going to be out
of scope anyway. Perhaps Doug (CC) can give us some ideas.

For what it's worth, the updated README on swift-evolution says:

"Beyond ABI stability (which focuses mostly on getting a bunch of low-level
implementation details of the language finalized), in Swift 5 the evolution
process welcomes additions that improve the overall usability of the
language and standard library"

So it sounds like they're willing to consider proposals outside of
ABI+concurrency—and though I can't speak for the core team's motivation, it
seems like requiring an implementation before formal review means that
proposals beyond their primary focus have a greater chance of making it
into the language than they did before.

···

On Mon, Aug 21, 2017 at 5:51 AM David Hart via swift-evolution < swift-evolution@swift.org> wrote:

On 21 Aug 2017, at 13:36, Adrian Zubarev <adrian.zubarev@devandartist.com> > wrote:

And my second question is: Wouldn’t the existence of this feature reshape
some parts of the standard library, isn’t that affecting some major goals
of Swift 5?

Yes. But that also true of many other language feature. But the Standard
Library still needs to be set in stone at some point or another.

It would be nice if someone from the core team can clarify if the where clause
is out of scope for Swift 5 or not.

Agreed.

Am 21. August 2017 um 12:51:48, David Hart (david@hartbit.com) schrieb:

On 21 Aug 2017, at 11:41, Adrian Zubarev <adrian.zubarev@devandartist.com> > wrote:

Yes, `where` clause is welcome to typealises (including generic ones) and
existentials in general. I would love to help on such proposal. I think
David Hart is also interested in this one. (cc)

Yes, this basically seems like *Generalized Existentials* to me and is
mentioned in the Generics Manifesto
<https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md>.
It’s a feature I hold very dear but:

   - It’s a very difficult feature to implement and I think Doug Gregor
   is the only/best person to do it
   - I think its pretty much out of scope for Swift 5 (it’s not required
   for ABI Stability)

As a result, I’d be very surprised if this topic got any discussion or
implementation time during the Swift 5 timeframe.

Am 21. August 2017 um 11:38:14, Gor Gyolchanyan via swift-evolution (
swift-evolution@swift.org) schrieb:

Hello, Swift community!

I'd like to start a discussion about a possibility of constrained protocol
aliases. The declaration would look like this:

typealias BinaryProtocol = RandomAccessCollection & MutablCollection &
RangeReplaceableCollection where Binary.Index == Int, Binary.Element ==
Bool

The syntax and semantics of this declaration are exactly the same as an
analogous associatedtype declaration inside a protocol.
In the example above, the type BinaryProtocol represents a logical array
of bits and is a generic-only protocol that is usable in any context where
an integer-indexed mutable range-replaceable random-access collection is
expected.
Now, it can be used in a very concise and elegant way:

public protocol BinaryInitializable {
init<Binary>(binary: Binary) where Binary: BinaryProtocol
}

which would otherwise look very verbose and inelegant:

public protocol BinaryInitializable {
init<Binary>(binary: Binary) where Binary: RandomAccessCollection &
MutablCollection & RangeReplaceableCollection, Binary.Index == Int, Binary
.Element == Bool
}

Considering that smaller sets of constraints could be aliased to their own
protocol and then composited into more complex aliases, this feature would
dramatically improve readability and maintainability of code that uses
complex constraints, that currently leads to arcane mess:

struct Mirror {

   - /// ...
   - init<Subject, C where C : Collection, C.Indices : Collection, C.
   SubSequence : Collection, C.Indices.Index == C.Index, C.Indices.
   SubSequence == C.Indices, C.Iterator.Element == Mirror.Child, C.
   SubSequence.Index == C.Index, C.SubSequence.Indices : Collection, C.
   SubSequence.SubSequence == C.SubSequence, C.Indices.Iterator.Element
    == C.Index, C.SubSequence.Indices.Index == C.Index, C.SubSequence.
   Indices.SubSequence == C.SubSequence.Indices, C.SubSequence.Iterator.
   Element == Mirror.Child, C.SubSequence.Indices.Iterator.Element == C.
   >(_ subject: Subject, children: C, displayStyle: Mirror.
   DisplayStyle? = default, ancestorRepresentation: Mirror.
   AncestorRepresentation = default)

/// ...
}

/// A collection that is its own sub-sequence
typealias RecursivelySliceableCollection = Collection where
RecursivelySliceableCollection.SubSequence: Collection,
RecursivelySliceableCollection.SubSequence.Element ==
RecursivelySliceableCollection.Element
RecursivelySliceableCollection.SubSequence.Indices ==
RecursivelySliceableCollection.Indices,
RecursivelySliceableCollection.SubSequence.SubSequence ==
RecursivelySliceableCollection.SubSequence

/// A collection that is its own index collection
typealias RecursivelyIndexableCollection = Collection where
RecursivelyIndexableCollection.Indices == RecursivelySliceableCollection,
RecursivelyIndexableCollection.Indices.Index ==
RecursivelyIndexableCollection.Index,

struct Mirror {
/// ...
init<Subject, C: RecursivelySliceableCollection &
RecursivelyIndexableCollection, where C.Element == Mirror.Child>(_
subject: Subject, children: C, displayStyle: Mirror.DisplayStyle? =
default, ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}

Even considering that the proposal SE-0157 (
https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md)
is going to make this specific use case a non-issue, the principle applies
to all cases where there are commonly used complex constraints that don't
necessarily involve recursive constraints.

*Specializing Generic-Only Protocols For Non-Generic Use*

An additional feature that would prove to be very useful would be to make
a constrained protocol alias be a non-generic-only protocol if the
constraints of the alias declaration specify a same-type requirement for
all its associated types, while defaulted associated types would also count.
Example:

protocol Consumer {
associatedtype Consumable
mutating func consume(_ consumable: Consumable) throws
}

var consumer0: Consumer // *error: Consumer is only usable in a generic
context*

typealias CharacterConsumer = Consumer where CharacterConsumer.Consumable
== Character

var consumer1: CharacterConsumer // OK

The current workaround would be to declare a new protocol with protocol
inheritance clauses and a where clause, but the major downside is that it
introduces a completely new protocol that is not compatible with any
context that expects the underlying protocols and their constraints.

Regards,
Gor Gyolchanyan.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Well I didn’t meant to say to spend time for something that will not even make into a review. If we can have some clarification from the core team, we still can decide if we’d tackle it or not. :wink:

Am 21. August 2017 um 14:51:06, David Hart (david@hartbit.com) schrieb:

···

On 21 Aug 2017, at 13:36, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:

It’s part of Generalized Existentials, but does not make it complete. I think it would be worth adding more and more functionality to existentials every year. We started first with reshaping the syntax. This year we added support for classes. I think next year would be good to have where clause support for typealiases.

I understand the complexity of that particular feature, and it’s a no-go for me to help on the implementation, but I’m willing to drive the discussion and the proposal forward with other co-authors. :slight_smile:

Hasn’t it been said that the implementation must be at least a *proof-of-concept* if the complexity is very high?

I’d love to have this feature. But I’m not sure even a partway proposal will get to review with the laser-focus on ABI Stability + Concurrency. I don’t want to spend time co-authoring a proposal if it is going to be out of scope anyway. Perhaps Doug (CC) can give us some ideas.
And my second question is: Wouldn’t the existence of this feature reshape some parts of the standard library, isn’t that affecting some major goals of Swift 5?

Yes. But that also true of many other language feature. But the Standard Library still needs to be set in stone at some point or another.
It would be nice if someone from the core team can clarify if the where clause is out of scope for Swift 5 or not.

Agreed.

Am 21. August 2017 um 12:51:48, David Hart (david@hartbit.com) schrieb:

On 21 Aug 2017, at 11:41, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:

Yes, `where` clause is welcome to typealises (including generic ones) and existentials in general. I would love to help on such proposal. I think David Hart is also interested in this one. (cc)

Yes, this basically seems like Generalized Existentials to me and is mentioned in the Generics Manifesto. It’s a feature I hold very dear but:

It’s a very difficult feature to implement and I think Doug Gregor is the only/best person to do it
I think its pretty much out of scope for Swift 5 (it’s not required for ABI Stability)

As a result, I’d be very surprised if this topic got any discussion or implementation time during the Swift 5 timeframe.
Am 21. August 2017 um 11:38:14, Gor Gyolchanyan via swift-evolution (swift-evolution@swift.org) schrieb:

Hello, Swift community!

I'd like to start a discussion about a possibility of constrained protocol aliases. The declaration would look like this:

typealias BinaryProtocol = RandomAccessCollection & MutablCollection & RangeReplaceableCollection where Binary.Index == Int, Binary.Element == Bool

The syntax and semantics of this declaration are exactly the same as an analogous associatedtype declaration inside a protocol.
In the example above, the type BinaryProtocol represents a logical array of bits and is a generic-only protocol that is usable in any context where an integer-indexed mutable range-replaceable random-access collection is expected.
Now, it can be used in a very concise and elegant way:

public protocol BinaryInitializable {
init<Binary>(binary: Binary) where Binary: BinaryProtocol
}

which would otherwise look very verbose and inelegant:

public protocol BinaryInitializable {
init<Binary>(binary: Binary) where Binary: RandomAccessCollection & MutablCollection & RangeReplaceableCollection, Binary.Index == Int, Binary.Element == Bool
}

Considering that smaller sets of constraints could be aliased to their own protocol and then composited into more complex aliases, this feature would dramatically improve readability and maintainability of code that uses complex constraints, that currently leads to arcane mess:

struct Mirror {
/// ...
init<Subject, C where C : Collection, C.Indices : Collection, C.SubSequence : Collection, C.Indices.Index == C.Index, C.Indices.SubSequence == C.Indices, C.Iterator.Element == Mirror.Child, C.SubSequence.Index == C.Index, C.SubSequence.Indices : Collection, C.SubSequence.SubSequence == C.SubSequence, C.Indices.Iterator.Element == C.Index, C.SubSequence.Indices.Index == C.Index, C.SubSequence.Indices.SubSequence == C.SubSequence.Indices, C.SubSequence.Iterator.Element == Mirror.Child, C.SubSequence.Indices.Iterator.Element == C.Index>(_ subject: Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}

/// A collection that is its own sub-sequence
typealias RecursivelySliceableCollection = Collection where
RecursivelySliceableCollection.SubSequence: Collection,
RecursivelySliceableCollection.SubSequence.Element == RecursivelySliceableCollection.Element
RecursivelySliceableCollection.SubSequence.Indices == RecursivelySliceableCollection.Indices,
RecursivelySliceableCollection.SubSequence.SubSequence == RecursivelySliceableCollection.SubSequence

/// A collection that is its own index collection
typealias RecursivelyIndexableCollection = Collection where
RecursivelyIndexableCollection.Indices == RecursivelySliceableCollection,
RecursivelyIndexableCollection.Indices.Index == RecursivelyIndexableCollection.Index,

struct Mirror {
/// ...
init<Subject, C: RecursivelySliceableCollection & RecursivelyIndexableCollection, where C.Element == Mirror.Child>(_ subject: Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}

Even considering that the proposal SE-0157 (https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md) is going to make this specific use case a non-issue, the principle applies to all cases where there are commonly used complex constraints that don't necessarily involve recursive constraints.

Specializing Generic-Only Protocols For Non-Generic Use

An additional feature that would prove to be very useful would be to make a constrained protocol alias be a non-generic-only protocol if the constraints of the alias declaration specify a same-type requirement for all its associated types, while defaulted associated types would also count.
Example:

protocol Consumer {
associatedtype Consumable
mutating func consume(_ consumable: Consumable) throws
}

var consumer0: Consumer // error: Consumer is only usable in a generic context

typealias CharacterConsumer = Consumer where CharacterConsumer.Consumable == Character

var consumer1: CharacterConsumer // OK

The current workaround would be to declare a new protocol with protocol inheritance clauses and a where clause, but the major downside is that it introduces a completely new protocol that is not compatible with any context that expects the underlying protocols and their constraints.

Regards,
Gor Gyolchanyan.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution