I don’t see a problem with your example. Because the typealias is fileprivate,
it doesn’t exist as far as MyUsefulType is concerned. The same way the
following works:
```
class Base {
private typealias Foo = Int
func foo() -> Int {
return Foo()
}
}
```
Other file:
```
class Derived: Base {
typealias Foo = String
func bar() -> String {
return "Hello \(foo())"
}
}
```
> On 09 May 2016, at 10:37, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>
> On Mon, May 9, 2016 at 2:31 AM, David Hart <da...@hartbit.com
> <mailto:da...@hartbit.com>> wrote:
>
>> On 09 May 2016, at 09:16, Xiaodi Wu <xiaodi...@gmail.com
>> <mailto:xiaodi...@gmail.com>> wrote:
>>
>> One more thought here:
>>
>> It goes a long way to say "typealiases in protocols are to have the same
>> semantics as aliases outside protocols." I'm inclined to agree on that, but
>> I haven't thought it totally through.
>>
>> Now, I can have private typealiases outside protocols. Could I have private
>> typealiases inside protocols? They'd be handy for referencing types while
>> implementing default methods in protocol extensions and whatnot without
>> worrying about collisions with typealiases in conforming types…
>
> Sounds like it should be allowed. I’ll add something about it in the
> proposal. Could you give an example of what you mean by "without worrying
> about collisions with typealiases in conforming types…”?
>
>
> I wonder if this takes things in an, um, interesting direction. Suppose I
> could have this (a contrived example--it may fall apart on further study):
>
> ```
> protocol MyUsefulProtocol {
> associatedtype Storage : Collection
> fileprivate typealias UniqueIdentifier = Storage.Index
> func doUsefulThing() -> Storage
> }
>
> extension MyUsefulProtocol {
> func doUsefulThing() -> Storage {
> // do something useful in this default implementation
> // use UniqueIdentifier internally here and only here
> }
> }
> ```
>
> In a different file:
>
> ```
> struct MyUsefulType<A : Hashable, B> : MyUsefulProtocol {
> /* I could do this if I wanted:
> typealias UniqueIdentifier = A
>
> More importantly, I could retroactively conform MyUsefulType
> to MyUsefulProtocol even if they happen to have clashing
> typealiases, which is great because the typealias in
> MyUsefulProtocol is used for clarity and convenience inside
> the default implementation and is irrelevant here
> */
> func doUsefulThing() -> Dictionary<A, B> {
> // do something useful but different
> // from the default implementation
> }
> }
> ```
>
> I wonder, though, if this is to be allowed, whether much the same could be
> achieved by instead allowing associatedtype declarations to have default
> values (for example: `associatedtype UniqueIdentifier : Equatable =
> Storage.Index`), at which point we might be one step away from going full
> circle and eliminating the distinction between associatedtypes and
> typealiases once again.
>
>
>> On Mon, May 9, 2016 at 01:52 David Hart <da...@hartbit.com
>> <mailto:da...@hartbit.com>> wrote:
>> I understand that name clashing in those instances is important to discuss,
>> but I still think it is slightly orthogonal to the proposal. Let me try to
>> explain why.
>>
>> If typealises in protocols are to have the same semantics as alises outside
>> protocols (as I think they should), then they don’t change anything about
>> the rules of collision. For example, the problem already exists today with
>> associated types:
>>
>> protocol Foo {
>> associatedtype Inner: IntegerType
>> func foo(inner: Inner)
>> }
>>
>> protocol Bar {
>> associatedtype Inner: FloatingPointType
>> var inner: Inner { get }
>> }
>>
>> struct FooBarImpl: Foo, Bar { // error: Type ‘FooBarImpl’ does not conform
>> to protocol ‘Bar'
>> func foo(inner: Int) {}
>> var inner: Float
>> }
>>
>> Type aliasing would not change anything about the fact that those collisions
>> already exists in the language and are not very well handled: either they
>> are meant to be forbidden but in that case we need better diagnostics, or we
>> want to have a way to work around them. Perhaps you’d like to start a
>> discussion around fixing that ?
>>
>>> On 09 May 2016, at 08:06, Xiaodi Wu <xiaodi...@gmail.com
>>> <mailto:xiaodi...@gmail.com>> wrote:
>>>
>>> I see your point that nothing breaks in the stdlib with your proposal
>>> alone. It's undeniably true--by construction!--that a purely additive
>>> feature, if never used, will not cause problems.
>>>
>>> That said, since the time that this feature was outlined in Doug's
>>> manifesto, I have been wondering how clashes such as the examples in my
>>> previous email are to be handled--i.e. what the rules of the language are
>>> to be--which I think is certainly germane to your proposal. Can a
>>> conforming type override a protocol typealias? Can a type conform to two
>>> protocols with conflicting typealiases if all requirements are otherwise
>>> satisfied? Surely, these merit discussion in your proposal.
>>>
>>> On Mon, May 9, 2016 at 12:48 AM David Hart <da...@hartbit.com
>>> <mailto:da...@hartbit.com>> wrote:
>>> Hello Xiaodi,
>>>
>>> What I mean by there is no impact on existing code is that the language
>>> change has no impact. Of course, if the Standard Library then declares a
>>> typealias Element in Sequence, it will clash with code which has declared
>>> an Element typealias in sub-protocols, but that is separate from the
>>> proposal.
>>>
>>>> On 09 May 2016, at 07:28, Xiaodi Wu <xiaodi...@gmail.com
>>>> <mailto:xiaodi...@gmail.com>> wrote:
>>>>
>>>> If the protocol Sequence has typealias Element, does that mean I also have
>>>> MyConformingSequence.Element?
>>>>
>>>> If so, I think there is a potential impact on existing code not mentioned.
>>>> Suppose MyConformingSequence already (unwisely) declares typealias
>>>> Element. Now, what happens when I try to migrate my code to your proposed
>>>> version of Swift?
>>>>
>>>> This is a toy example, of course. More generally, though, I wonder about
>>>> this question:
>>>>
>>>> Suppose two protocols A and B each declare typealias Element. These
>>>> typealiases are, as you proposed, intended to simplify referencing
>>>> indirect associated types. But are they themselves considered protocol
>>>> requirements?
>>>>
>>>> I ask because, suppose I want to conform type T to A and B. I implement
>>>> all the required methods and properties for such conformance. I declare
>>>> the appropriate typealiases for the associatedtypes declared in both
>>>> protocols. But, if A.Element and B.Element are incompatible with each
>>>> other, it is nonetheless impossible to conform T to both A and B? If it's
>>>> forbidden, isn't that kind of a bummer, since what's getting in the way is
>>>> a naming clash arising from a facility intended to simplify the naming of
>>>> things rather than provide for new functionality? If it's permitted, what
>>>> is T.Element? Some clarity here would be nice.
>>>> On Sun, May 8, 2016 at 6:17 PM David Hart via swift-evolution
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> Hello,
>>>>
>>>> I’ve come again with another proposal directly from the Generics
>>>> Manifesto. Please let me know if it needs any modifications before sending
>>>> the pull request.
>>>>
>>>> Typealiases in protocols and protocol extensions
>>>>
>>>> Proposal: SE-XXXX
>>>> <https://github.com/hartbit/swift-evolution/blob/typealiases-in-protocols/proposals/XXXX-typealiases-in-protocols.md>
>>>> Authors: David Hart <https://github.com/hartbit>, Doug Gregor
>>>> <https://github.com/DougGregor>
>>>> Status: TBD
>>>> Review manager: TBD
>>>>
>>>> <https://github.com/hartbit/swift-evolution/blob/typealiases-in-protocols/proposals/XXXX-typealiases-in-protocols.md#introduction>Introduction
>>>>
>>>> This proposal is from the Generics Manifesto
>>>> <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md> and
>>>> brings the typealias keyword back into protocols for type aliasing.
>>>>
>>>>
>>>> <https://github.com/hartbit/swift-evolution/blob/typealiases-in-protocols/proposals/XXXX-typealiases-in-protocols.md#motivation>Motivation
>>>>
>>>> In Swift versions prior to 2.2, the typelias keyword was used outside of
>>>> protocols to declare type aliases and in protocols to declare associated
>>>> types. Since SE-0011
>>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md>
>>>> and Swift 2.2, associated type now use the associatedtype keyword and
>>>> typelias is available for implementing true associated type aliases.
>>>>
>>>>
>>>> <https://github.com/hartbit/swift-evolution/blob/typealiases-in-protocols/proposals/XXXX-typealiases-in-protocols.md#proposed-solution>Proposed
>>>> solution
>>>>
>>>> The solution allows the creation of associated type aliases. Here is an
>>>> example from the standard library:
>>>>
>>>> protocol Sequence {
>>>> associatedtype Iterator : IteratorProtocol
>>>> typealias Element = Iterator.Element
>>>> }
>>>> The example above shows how this simplifies referencing indirect
>>>> associated types:
>>>>
>>>> func sum<T: Sequence where T.Element == Int>(sequence: T) -> Int {
>>>> return sequence.reduce(0, combine: +)
>>>> }
>>>>
>>>> <https://github.com/hartbit/swift-evolution/blob/typealiases-in-protocols/proposals/XXXX-typealiases-in-protocols.md#detailed-design>Detailed
>>>> design
>>>>
>>>> The following grammar rules needs to be added:
>>>>
>>>> protocol-member-declaration → protocol-typealias-declaration
>>>>
>>>> protocol-typealias-declaration → typealias-declaration
>>>>
>>>>
>>>> <https://github.com/hartbit/swift-evolution/blob/typealiases-in-protocols/proposals/XXXX-typealiases-in-protocols.md#impact-on-existing-code>Impact
>>>> on existing code
>>>>
>>>> This will have no impact on existing code, but will probably require
>>>> improving the Fix-It that was created for migrating typealias to
>>>> associatedtype in Swift 2.2.
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>
>>
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
