Sorry--I'm not at all saying that I think there's a problem. As you asked, I attempted to supply a contrived use case for a typealias declared in a protocol having a more restricted scope than the protocol itself. I was asking if it would be supported as part of your proposal.
On Mon, May 9, 2016 at 3:11 PM, David Hart <[email protected]> wrote: > 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 <[email protected]> wrote: > > On Mon, May 9, 2016 at 2:31 AM, David Hart <[email protected]> wrote: > >> >> On 09 May 2016, at 09:16, Xiaodi Wu <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 < >>>> [email protected]> 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 >>>>> [email protected] >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >>>> >>>> >>> >> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
