In Swift 4:
protocol P1 {
associatedtype A: P1 // Error: Type may not reference itself as a
requirement
}
protocol P2 {
associatedtype A where A: P2 // OK
}
What is the rationale behind this?
/Jens
This is a rather complex feature that is not actually implemented in Swift 4 (or Swift 3 for that matter). Work is underway to support this, though. The fact that the second example does not produce a diagnostic is a bug (probably you will not be able to define a type that conforms to P2 anyway).
The proposal is here if you’d like to read more about it: https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md
Slava
···
On Jun 6, 2017, at 10:37 PM, Jens Persson via swift-users <swift-users@swift.org> wrote:
In Swift 4:
protocol P1 {
associatedtype A: P1 // Error: Type may not reference itself as a requirement
}
protocol P2 {
associatedtype A where A: P2 // OK
}What is the rationale behind this?
/Jens
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Ok, I thought it was part of SE-0142 (which has status "implemented (Swift
4)".
/Jens
···
On Wed, Jun 7, 2017 at 9:39 AM, Slava Pestov <spestov@apple.com> wrote:
This is a rather complex feature that is not actually implemented in Swift
4 (or Swift 3 for that matter). Work is underway to support this, though.
The fact that the second example does not produce a diagnostic is a bug
(probably you will not be able to define a type that conforms to P2 anyway).The proposal is here if you’d like to read more about it:
GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
proposals/0157-recursive-protocol-constraints.mdSlava
> On Jun 6, 2017, at 10:37 PM, Jens Persson via swift-users < > swift-users@swift.org> wrote:
>
> In Swift 4:
>
> protocol P1 {
> associatedtype A: P1 // Error: Type may not reference itself as a
requirement
> }
> protocol P2 {
> associatedtype A where A: P2 // OK
> }
>
> What is the rationale behind this?
>
> /Jens
> _______________________________________________
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
Ok, I thought it was part of SE-0142 (which has status "implemented (Swift 4)”.
That’s just the where clause part. There’s still plenty you can accomplish with them even if they do not introduce recursive conformances :)
Slava
···
On Jun 7, 2017, at 12:46 AM, Jens Persson <jens@bitcycle.com> wrote:
/Jens
On Wed, Jun 7, 2017 at 9:39 AM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com>> wrote:
This is a rather complex feature that is not actually implemented in Swift 4 (or Swift 3 for that matter). Work is underway to support this, though. The fact that the second example does not produce a diagnostic is a bug (probably you will not be able to define a type that conforms to P2 anyway).The proposal is here if you’d like to read more about it: https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md
Slava
> On Jun 6, 2017, at 10:37 PM, Jens Persson via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>
> In Swift 4:
>
> protocol P1 {
> associatedtype A: P1 // Error: Type may not reference itself as a requirement
> }
> protocol P2 {
> associatedtype A where A: P2 // OK
> }
>
> What is the rationale behind this?
>
> /Jens
> _______________________________________________
> swift-users mailing list
> swift-users@swift.org <mailto:swift-users@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-users
I see, this quote from the introduction of SE-0142 is not to be taken
literally then:
For example, the SequenceType protocol could be declared as follows if the
current proposal was accepted:
protocol Sequence {
associatedtype Iterator : IteratorProtocol
associatedtype SubSequence : Sequence where
SubSequence.Iterator.Element == Iterator.Element
...
}
Don't want to nitpick, but it's hard to follow Swift's evolution when
proposals like eg SE-0142 (and eg SE-0110) can have status "implemented"
even though they contain statements and examples like the above which
simply are not true (when compared to the compiler which supposedly
implements the proposal).
Is there somewhere I can see what *part(s)* of an "implemented" proposal
are *actually implemented*?
Otherwise, I think it would be less confusing if partly implemented
proposals were marked as such.
/Jens
···
On Wed, Jun 7, 2017 at 9:47 AM, Slava Pestov <spestov@apple.com> wrote:
On Jun 7, 2017, at 12:46 AM, Jens Persson <jens@bitcycle.com> wrote:
Ok, I thought it was part of SE-0142 (which has status "implemented (Swift
4)”.That’s just the where clause part. There’s still plenty you can accomplish
with them even if they do not introduce recursive conformances :)Slava
/Jens
On Wed, Jun 7, 2017 at 9:39 AM, Slava Pestov <spestov@apple.com> wrote:
This is a rather complex feature that is not actually implemented in
Swift 4 (or Swift 3 for that matter). Work is underway to support this,
though. The fact that the second example does not produce a diagnostic is a
bug (probably you will not be able to define a type that conforms to P2
anyway).The proposal is here if you’d like to read more about it:
https://github.com/apple/swift-evolution/blob/master/proposa
ls/0157-recursive-protocol-constraints.mdSlava
> On Jun 6, 2017, at 10:37 PM, Jens Persson via swift-users < >> swift-users@swift.org> wrote:
>
> In Swift 4:
>
> protocol P1 {
> associatedtype A: P1 // Error: Type may not reference itself as a
requirement
> }
> protocol P2 {
> associatedtype A where A: P2 // OK
> }
>
> What is the rationale behind this?
>
> /Jens
> _______________________________________________
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
I think that’s just a poor example in the proposal. Constraining "SubSequence: Sequence" is not actually part of SE-0142.
As for implementation status, usually I check the changelog (https://github.com/apple/swift/blob/master/CHANGELOG.md\)
- Karl
···
On 7. Jun 2017, at 11:29, Jens Persson via swift-users <swift-users@swift.org> wrote:
I see, this quote from the introduction of SE-0142 is not to be taken literally then:
For example, the SequenceType protocol could be declared as follows if the current proposal was accepted:
protocol Sequence {
associatedtype Iterator : IteratorProtocol
associatedtype SubSequence : Sequence where SubSequence.Iterator.Element == Iterator.Element
...
}Don't want to nitpick, but it's hard to follow Swift's evolution when proposals like eg SE-0142 (and eg SE-0110) can have status "implemented" even though they contain statements and examples like the above which simply are not true (when compared to the compiler which supposedly implements the proposal).
Is there somewhere I can see what *part(s)* of an "implemented" proposal are *actually implemented*?
Otherwise, I think it would be less confusing if partly implemented proposals were marked as such.
/Jens
Ok, thanks!
···
On Wed, Jun 7, 2017 at 4:52 PM, Karl Wagner <razielim@gmail.com> wrote:
On 7. Jun 2017, at 11:29, Jens Persson via swift-users < > swift-users@swift.org> wrote:
I see, this quote from the introduction of SE-0142 is not to be taken
literally then:For example, the SequenceType protocol could be declared as follows if the
current proposal was accepted:protocol Sequence {
associatedtype Iterator : IteratorProtocol
associatedtype SubSequence : Sequence where
SubSequence.Iterator.Element == Iterator.Element
...
}Don't want to nitpick, but it's hard to follow Swift's evolution when
proposals like eg SE-0142 (and eg SE-0110) can have status "implemented"
even though they contain statements and examples like the above which
simply are not true (when compared to the compiler which supposedly
implements the proposal).Is there somewhere I can see what *part(s)* of an "implemented" proposal
are *actually implemented*?Otherwise, I think it would be less confusing if partly implemented
proposals were marked as such./Jens
I think that’s just a poor example in the proposal. Constraining
"SubSequence: Sequence" is not actually part of SE-0142.As for implementation status, usually I check the changelog (
https://github.com/apple/swift/blob/master/CHANGELOG.md\)- Karl