Re: [swift-users] Extensions on Typealiased Existential Protocols
@David But the automatic conformance is currently supported through
extension A where Self: B.
@Slava When does extension A where Self: B not equal extension B where Self:
A? Why would protocol inheritance not be communicative?
On June 19, 2017 at 5:26:44 PM, David Sweeris (daveswee...@mac.com) wrote:
IIUC (which shouldn't be assumed on your part) the difference is that any
types which conform to both `A` and `B` will *automatically* conform to
`CProtocol` as well, but not `C`. I suspect the "automatic conformance" bit
is why we don't currently allow it.
- Dave Sweeris
On Jun 19, 2017, at 13:44, Jon Shier via swift-users <swift-users@swift.org>
wrote:
What I usually do here is:
typealias CProtocol = A & B
protocol C: CProtocol { } // or just A & B directly, I think
extension C {}
So it’s a bit silly to me.
Jon
On Jun 19, 2017, at 3:44 PM, Slava Pestov via swift-users <
swift-users@swift.org> wrote:
Hi Steven,
On Jun 19, 2017, at 11:44 AM, Steven Brunwasser via swift-users <
swift-users@swift.org> wrote:
Is this error intentional, or a bug?
It’s intentional. We could add support for this as an extra bit of sugar,
but note that
Since extension A where Self: B is the same as extension B where Self: A,
This is not quite true.
Slava
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
[swift-users] Extensions on Typealiased Existential Protocols
Is this error intentional, or a bug?
protocol A {}
protocol B {}
typealias C = A & B // valid
extension C {} // Error: Non-nominal type 'C' (aka 'A & B') cannot be
extended
extension A where Self: B {} // valid
struct Foo: C {} // valid
Since extension A where Self: B is the same as extension B where Self: A,
and C is defined as any A that also inherits from B, shouldn’t extension C be
just as valid?
This seems like it should be valid, so I filed this bug,
https://bugs.swift.org/browse/SR-5260.
- Steve
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Associatedtype Naming Conventions
Yes, I understand this. I was just wondering if there was a naming
convention I should use to differentiate them.
Should I use a few letters as a prefix? Should I use the full protocol name
as a prefix? Or is there another suggestion for a naming convention?
I'm also curious about any naming conventions I should use to get around
collisions with other libraries' protocol associatedtypes.
On May 31, 2017 at 16:26:52, Slava Pestov (spes...@apple.com) wrote:
>
> On May 31, 2017, at 4:16 PM, Steven Brunwasser <sbrunwas...@gmail.com>
> wrote:
>
> Basically, my library contains a bunch of collection-like protocols, which
> can be combined in different ways and can be compatible with each other in
> certain combinations when the proper types align. Naturally, they all have
> an Element associatedtype, but I need to allow for the possibility where
> two of these collection protocols are implemented in the same structure
> that requires different type definitions for each protocols' Element.
>
>
> Oh, I understand now. This is intentionally not supported — associated
> types with the same name from different protocols must all be implemented
> by the same typealias in the conforming type.
>
> Slava
>
>
> I’ve been trying to make some other protocols to simplify some
> definitions, but specifying a parent protocol’s associated type within a
> child protocol doesn’t seem to work.
>
> protocol Buzz: Bar {
> typealias Container = A
> }
>
> struct BuzzImpl: Buzz {} // *error: type ‘BuzzImpl' does not conform to
> protocol ‘Buzz'*
>
> On May 31, 2017 at 4:02:43 PM, Slava Pestov (spes...@apple.com) wrote:
>
> Can you give an example of a problematic name collision? Does fully
> qualifying names not help?
>
> Slava
>
> On May 31, 2017, at 4:01 PM, Steven Brunwasser via swift-users <
> swift-users@swift.org> wrote:
>
> Hi,
>
> I have a library which uses a few generic protocols with identically named
> associated types that may not always be specified identically by
> implementors.
>
> protocol Foo {
> associatedtype Container
> associatedtype Element
> }
>
> protocol Bar {
> associatedtype Container
> associatedtype Element
> }
>
> struct Baz: Foo, Bar {
> // Implement using two different Container/Element types.
> }
>
> Is there a consensus on some naming convention for associatedtypes to
> mitigate name collisions?
> Would it be acceptable to add namespace prefixes to these types?
>
> protocol Foo {
> associatedtype FooContainer
> associatedtype FooElement
> }
>
> I’m using the dictionary and thesaurus to find some alternative names I
> could use, but the ones already used are so the most sensical semantically.
>
> Do you have any suggestions?
>
> Thanks,
> - Steve Brunwasser
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Associatedtype Naming Conventions
By fully qualifying names, do you mean something like this?
struct Baz: Foo, Bar {
typealias Foo.Container = A
typealias Bar.Container = B
}
This seems to be invalid, at least in Swift 3.1.
Basically, my library contains a bunch of collection-like protocols, which
can be combined in different ways and can be compatible with each other in
certain combinations when the proper types align. Naturally, they all have
an Element associatedtype, but I need to allow for the possibility where
two of these collection protocols are implemented in the same structure
that requires different type definitions for each protocols' Element.
I’ve been trying to make some other protocols to simplify some definitions,
but specifying a parent protocol’s associated type within a child protocol
doesn’t seem to work.
protocol Buzz: Bar {
typealias Container = A
}
struct BuzzImpl: Buzz {} // *error: type ‘BuzzImpl' does not conform to
protocol ‘Buzz'*
On May 31, 2017 at 4:02:43 PM, Slava Pestov (spes...@apple.com) wrote:
Can you give an example of a problematic name collision? Does fully
qualifying names not help?
Slava
On May 31, 2017, at 4:01 PM, Steven Brunwasser via swift-users <
swift-users@swift.org> wrote:
Hi,
I have a library which uses a few generic protocols with identically named
associated types that may not always be specified identically by
implementors.
protocol Foo {
associatedtype Container
associatedtype Element
}
protocol Bar {
associatedtype Container
associatedtype Element
}
struct Baz: Foo, Bar {
// Implement using two different Container/Element types.
}
Is there a consensus on some naming convention for associatedtypes to
mitigate name collisions?
Would it be acceptable to add namespace prefixes to these types?
protocol Foo {
associatedtype FooContainer
associatedtype FooElement
}
I’m using the dictionary and thesaurus to find some alternative names I
could use, but the ones already used are so the most sensical semantically.
Do you have any suggestions?
Thanks,
- Steve Brunwasser
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
[swift-users] Associatedtype Naming Conventions
Hi,
I have a library which uses a few generic protocols with identically named
associated types that may not always be specified identically by
implementors.
protocol Foo {
associatedtype Container
associatedtype Element
}
protocol Bar {
associatedtype Container
associatedtype Element
}
struct Baz: Foo, Bar {
// Implement using two different Container/Element types.
}
Is there a consensus on some naming convention for associatedtypes to
mitigate name collisions?
Would it be acceptable to add namespace prefixes to these types?
protocol Foo {
associatedtype FooContainer
associatedtype FooElement
}
I’m using the dictionary and thesaurus to find some alternative names I
could use, but the ones already used are so the most sensical semantically.
Do you have any suggestions?
Thanks,
- Steve Brunwasser
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
