Extremely strong +1. I’ve got a bunch of Objective-C-style really long type names of the sort “MyProtocol”, “MyProtocolSomeTypeEnum”, “MyProtocolSomeOptionsEnum”, etc. It would be really nice to make those Swiftier.
Charles > On Oct 17, 2016, at 12:59 PM, Karl via swift-evolution > <[email protected]> wrote: > > I was just doing some googling, turns out there was a discussion about > nesting protocols in other types that seemed to go positively a long time > ago: > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/016074.html > > <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/016074.html> > > I would additionally like to propose that protocols be allowed to contain > nested types (including other protocols). Relevant ABI issue is that the > standard library contains enums for “FloatingPointRoundingRule”, > “FloatingPointClassification” and “FloatingPointSign”. They would probably be > better expressed as “FloatingPoint.RoundingRule”, “.Sign", etc. > > so to summarise, newly legal would be: > > class MyClass { > > protocol Delegate { > } > } > > and also: > > protocol MyProto { > > enum SomeValue { > } > > protocol Delegate { > associatedType ExpectedContent > > func receive(_: ExpectedContent, for: SomeValue) > > protocol SecondaryTarget { > func receive(_ : ExpectedContent) > } > } > } > > When conforming to a nested protocol, you can just use the name of the > protocol: > > class Host : MyProto.Delegate { > } > > Except if a protocol in the chain has associated types, then you must use a > concrete, conforming type instead (as you would in the first example — > MyClass.Delegate): > > class SecondaryProcessor : Host.SecondaryTarget { > } > > If we’re good with this, I’ll write up a proposal. > > - 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
