[swift-users] Associatedtype Naming Conventions

[Steven Brunwasser]

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 (spestov at 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 at 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 at swift.org
https://lists.swift.org/mailman/listinfo/swift-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20170531/6b0c7dbb/attachment.html>