Is there another proposal directly related to namespacing ? This would seem like addressing a bit of the same issue.. As an example i would much prefer writing something like :
Package UITableView Class Table : UIView Class Cell : UIView Protocol Delegate Protocol Datasource With each class in a different file, under a common folder named after the namespace, rather than a mumbo jumbo of structs enums and protocols all wrapping each others. The only advantage of nesting i would think about is to be able to capture something from the parent context. But since that’s a potential snake pit, i’d rather not even start going in that direction. > Le 27 nov. 2017 à 00:12, Jonathan Hull via swift-evolution > <[email protected]> a écrit : > > I would use this pretty much constantly! I thought it was going to be in > Swift 4, and have really been missing it… > > >> On Nov 26, 2017, at 8:51 AM, Adrian Zubarev via swift-evolution >> <[email protected]> wrote: >> >> >> What happened to this? Should we revive this talk? I’d love to finally be >> able to nest protocols in Swift 5 and clean up my code. >> >> Am 18. Januar 2017 um 09:48:20, Slava Pestov via swift-evolution >> ([email protected]) schrieb: >> >>> I left some review comments here: >>> >>> https://github.com/apple/swift-evolution/commit/ff654e4 >>> >>> Slava >>> >>>>> On Jan 18, 2017, at 12:17 AM, Karl Wagner <[email protected]> wrote: >>>>> >>>>> >>>>>> On 18 Jan 2017, at 01:07, Douglas Gregor <[email protected]> wrote: >>>>>> >>>>>> >>>>>>> On Nov 5, 2016, at 2:44 AM, Karl via swift-evolution >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> >>>>>>>> On 2 Nov 2016, at 20:54, Slava Pestov <[email protected]> wrote: >>>>>>>> >>>>>>>> >>>>>>>>> On Nov 2, 2016, at 8:32 AM, Paul Cantrell <[email protected]> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Oct 24, 2016, at 4:43 PM, Slava Pestov <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Oct 24, 2016, at 8:12 AM, Paul Cantrell <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Oct 24, 2016, at 5:09 AM, Slava Pestov via swift-evolution >>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>> However protocols nested inside types and types nested inside >>>>>>>>>>> protocols is still not supported, because protocols introduce a >>>>>>>>>>> separate series of issues involving associated types and the ’Self’ >>>>>>>>>>> type. >>>>>>>>>>> >>>>>>>>>>> The hard part of getting nested generics right is what to do if a >>>>>>>>>>> nested type ‘captures’ generic parameters of the outer type. For >>>>>>>>>>> non-protocol types, the behavior here is pretty straightforward. >>>>>>>>>>> >>>>>>>>>>> If we allow protocols to be nested inside other types, we have to >>>>>>>>>>> decide what to do if the protocol ‘closes over’ generic parameters >>>>>>>>>>> of the outer type. For example, >>>>>>>>>>> >>>>>>>>>>> struct A<T> { >>>>>>>>>>> protocol P { >>>>>>>>>>> func requirement() -> T >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> Presumably A<Int>.P and A<String>.P are distinct types, and A.P has >>>>>>>>>>> a hidden associated type corresponding to the type parameter ’T’? >>>>>>>>>>> >>>>>>>>>>> The other case is problematic too — the nested type might refer to >>>>>>>>>>> an associated type of the outer protocol: >>>>>>>>>>> >>>>>>>>>>> protocol P { >>>>>>>>>>> associatedtype A >>>>>>>>>>> >>>>>>>>>>> struct T { >>>>>>>>>>> var value: A >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> Now writing P.T does not make sense, for the same reason that we >>>>>>>>>>> cannot form an existential of type P.A. We could prohibit >>>>>>>>>>> references to outer associated types of this form, or we could >>>>>>>>>>> figure out some way to give it a meaning. If C is a concrete type >>>>>>>>>>> conforming to P, then certainly C.T makes sense, for instance. >>>>>>>>>>> Internally, the nested type A.T could have a hidden ‘Self’ generic >>>>>>>>>>> type parameter, so that writing C.T is really the same as P.T<C>. >>>>>>>>>>> >>>>>>>>>>> Protocols nested inside protocols also have the same issue. >>>>>>>>>> >>>>>>>>>> FWIW, in almost all the situations where I’ve wanted to nest types >>>>>>>>>> inside protocols and generic types, it’s only as a namespacing >>>>>>>>>> convenience. Most often, it’s an enum type that’s used only by a >>>>>>>>>> single method, and having it at the top of the module namespace adds >>>>>>>>>> clutter. >>>>>>>>>> >>>>>>>>>> Here’s a real life example pared down. I wish I could do this: >>>>>>>>>> >>>>>>>>>> public struct ResponseContentTransformer<InputContentType, >>>>>>>>>> OutputContentType>: ResponseTransformer { >>>>>>>>>> >>>>>>>>>> public init(onInputTypeMismatch mismatchAction: >>>>>>>>>> InputTypeMismatchAction = .error) { >>>>>>>>>> ... >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> public enum InputTypeMismatchAction { // Does not depend on >>>>>>>>>> generic types above >>>>>>>>>> case error >>>>>>>>>> case skip >>>>>>>>>> case skipIfOutputTypeMatches >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> InputTypeMismatchAction is tightly associated with >>>>>>>>>> ResponseContentTransformer, and is confusing as a top-level type. >>>>>>>>>> >>>>>>>>>> What do you think about providing a “no captures” modifier for >>>>>>>>>> nested types — like static inner classes in Java? Then Swift could >>>>>>>>>> provide the namespace nesting I wish for this without having to >>>>>>>>>> resolve the trickier type capture questions yet. >>>>>>>>>> >>>>>>>>>> Alternatively, what if (1) outer types aren’t capture unless they’re >>>>>>>>>> referenced, and (2) nesting is only illegal if there’s a capture? >>>>>>>>>> Then my code above would compile, as would this: >>>>>>>>>> >>>>>>>>>> public struct S<T> { >>>>>>>>>> public enum Foo { >>>>>>>>>> case yin >>>>>>>>>> case yang >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> …but this wouldn’t: >>>>>>>>>> >>>>>>>>>> public struct S<T> { >>>>>>>>>> public enum Foo { >>>>>>>>>> case yin(thing: T) // capture of T illegal (for now) >>>>>>>>>> case yang >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> Either of these approaches would allow hygienic namespacing now >>>>>>>>>> while leaving the door open to outer type capture in the future. >>>>>>>>> >>>>>>>>> Yeah, this makes sense for a first cut at this feature. >>>>>>>>> >>>>>>>>> Slava >>>>>>>> >>>>>>>> Should I take a crack at writing up a proposal for this? Now? After >>>>>>>> ABI work is done? (Probably the latter “OK if no captures” approach?) >>>>>>>> Eager to help; don’t want to be in the way. >>>>>>> >>>>>>> Just speaking for myself and not the whole team — I think you can >>>>>>> submit the proposal at any time, we’re unlikely to get around to doing >>>>>>> it, if you want to take a crack that would be great (again, with ‘no >>>>>>> captures’ it’s “trivial”). >>>>>>> >>>>>>> Slava >>>>>>> >>>>>>>> >>>>>>>> P >>>>>> >>>>>> >>>>>> Sorry, let this slip. Proposal sent - >>>>>> https://github.com/apple/swift-evolution/pull/552 >>>>> >>>>> (Coming back to this after a very long time) >>>>> >>>>> One very high-level comment: one of your early examples is making the >>>>> Delegate of a view. Did you consider making this an Objective-C >>>>> translation rule as well, so that *Delegate and *DataSource protocols >>>>> would be imported as nested types within a class with the name signified >>>>> by *, e.g., >>>>> >>>>> class UITableView { >>>>> @objc(UITableViewDataSource) >>>>> protocol DataSource { … } >>>>> >>>>> @objc(UITableViewDelegate) >>>>> protocol Delegate { … } >>>>> } >>>>> >>>>> - Doug >>>>> >>>>> >>>> >>>> Yes, and platform SDK changes are mentioned under “Source Compatibility”. >>>> >>>> I’ve removed the standard library stuff from it now, that can happen >>>> later. Would we be able to get the ball rolling on getting it reviewed? >>>> >>>> Thanks >>>> >>>> - Karl >>>> >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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
