Re: [swift-evolution] Constrained Protocol Aliases

[Douglas Gregor via swift-evolution]

> On Aug 21, 2017, at 5:51 AM, David Hart  wrote:
> 
> 
>> On 21 Aug 2017, at 13:36, Adrian Zubarev > > 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. :)
>> 
>> 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

> 
>> 
>> Am 21. August 2017 um 12:51:48, David Hart (da...@hartbit.com 
>> ) schrieb:
>> 
>>> 
 On 21 Aug 2017, at 11:41, Adrian Zubarev > 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:
> 
> 

Re: [swift-evolution] Constrained Protocol Aliases

[Matthew Johnson via swift-evolution]

> On Aug 21, 2017, at 10:31 AM, Adrian Zubarev 
>  wrote:
> 
> 
> 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.

> 
> Am 21. August 2017 um 15:10:34, Matthew Johnson (matt...@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/-enhanced-existentials.md
>>  
>> .
>> 
>> Sent from my iPad
>> 
>> On Aug 21, 2017, at 6:36 AM, Adrian Zubarev via swift-evolution 
>> > 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. :)
>>> 
>>> 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 (da...@hartbit.com 
>>> ) schrieb:
>>> 
 
> On 21 Aug 2017, at 11:41, Adrian Zubarev  > 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) where Binary: 

Re: [swift-evolution] Constrained Protocol Aliases

[Adrian Zubarev via 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 (matt...@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/-enhanced-existentials.md.

Sent from my iPad

On Aug 21, 2017, at 6:36 AM, Adrian Zubarev via swift-evolution 
 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. :)

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 (da...@hartbit.com) schrieb:


On 21 Aug 2017, at 11:41, Adrian Zubarev  
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) where Binary: BinaryProtocol
}

which would otherwise look very verbose and inelegant:

public protocol BinaryInitializable {
init(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: Subject, 
children: C, displayStyle: Mirror.DisplayStyle? = default, 
ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}


/// A 

Re: [swift-evolution] Constrained Protocol Aliases

[Adrian Zubarev via 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. ;)




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


On 21 Aug 2017, at 13:36, Adrian Zubarev  
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. :)

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 (da...@hartbit.com) schrieb:


On 21 Aug 2017, at 11:41, Adrian Zubarev  
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) where Binary: BinaryProtocol
}

which would otherwise look very verbose and inelegant:

public protocol BinaryInitializable {
init(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: 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

Re: [swift-evolution] Constrained Protocol Aliases

[Tony Allevato via swift-evolution]

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 
> 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. :)
>
> 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.


> 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 (da...@hartbit.com) schrieb:
>
>
> On 21 Aug 2017, at 11:41, Adrian Zubarev 
> 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) where Binary: BinaryProtocol
> }
>
> which would otherwise look very verbose and inelegant:
>
> public protocol BinaryInitializable {
> init(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 {
>
>- /// ...
>- initSubSequence : 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, 

Re: [swift-evolution] Constrained Protocol Aliases

[Matthew Johnson via 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/-enhanced-existentials.md.

Sent from my iPad

> On Aug 21, 2017, at 6:36 AM, Adrian Zubarev via swift-evolution 
>  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. :)
> 
> 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 (da...@hartbit.com) schrieb:
> 
>> 
>>> On 21 Aug 2017, at 11:41, Adrian Zubarev  
>>> 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) where Binary: BinaryProtocol
 }
 
 which would otherwise look very verbose and inelegant:
 
 public protocol BinaryInitializable {
 init(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: Subject, 
 children: C, displayStyle: Mirror.DisplayStyle? = default, 
 ancestorRepresentation: Mirror.AncestorRepresentation = default)
 /// ...
 }
 
 
 /// A collection that is its own sub-sequence
 typealias RecursivelySliceableCollection = 

Re: [swift-evolution] Constrained Protocol Aliases

[David Hart via swift-evolution]

> On 21 Aug 2017, at 13:36, Adrian Zubarev  
> 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. :)
> 
> 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 (da...@hartbit.com 
> ) schrieb:
> 
>> 
>>> On 21 Aug 2017, at 11:41, Adrian Zubarev >> > 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) where Binary: BinaryProtocol
 }
 
 which would otherwise look very verbose and inelegant:
 
 public protocol BinaryInitializable {
 init(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: Subject, 
 children: C, displayStyle: Mirror.DisplayStyle? = default, 
 ancestorRepresentation: Mirror.AncestorRepresentation = default)
 /// ...
 }
 
 

Re: [swift-evolution] Constrained Protocol Aliases

[Adrian Zubarev via 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. :)

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 (da...@hartbit.com) schrieb:


On 21 Aug 2017, at 11:41, Adrian Zubarev  
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) where Binary: BinaryProtocol
}

which would otherwise look very verbose and inelegant:

public protocol BinaryInitializable {
init(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: 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: 
Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, 
ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}

Even considering that the proposal SE-0157 

Re: [swift-evolution] Constrained Protocol Aliases

[David Hart via swift-evolution]

> On 21 Aug 2017, at 11:41, Adrian Zubarev  
> 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) where Binary: BinaryProtocol
>> }
>> 
>> which would otherwise look very verbose and inelegant:
>> 
>> public protocol BinaryInitializable {
>> init(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> : 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> 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 

Re: [swift-evolution] Constrained Protocol Aliases

[Gor Gyolchanyan via 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! 

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 
>  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 ) 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) where Binary: BinaryProtocol
>> }
>> 
>> which would otherwise look very verbose and inelegant:
>> 
>> public protocol BinaryInitializable {
>> init(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> : 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> 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 

Re: [swift-evolution] Constrained Protocol Aliases

[Adrian Zubarev via 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)


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) where Binary: BinaryProtocol
}

which would otherwise look very verbose and inelegant:

public protocol BinaryInitializable {
init(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: 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: 
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

[swift-evolution] Constrained Protocol Aliases

[Gor Gyolchanyan via swift-evolution]

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) where Binary: BinaryProtocol
}

which would otherwise look very verbose and inelegant:

public protocol BinaryInitializable {
init(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: 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: 
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