> On 21 Nov 2016, at 13:29, Derrick Ho via swift-evolution > <[email protected]> wrote: > > Actually this is very consistent. You can not nest data structures like > enums, structs, or classes in a protocol. This is because a protocol is meant > to be a list of variables and functions that data structures may conform to. > A protocol is not a data structure.
While that's generally correct, a nested type isn't really part of the type that it comes within; it's still a discreet type stored elsewhere, the nesting is just to make it a bit nicer to work with, rather than defining types with overly long names. It's more of a naming/grouping system. I'm generally in favour of allow nested types for protocols personally, as really the only caveat is that it may make collisions more likely; for example if several protocols have a nested type of ReturnType, or Node or whatever then you'll have to also name the parent type when referencing them, though in most cases type inference may prevent this from being much a problem. So yeah, I think there's definitely an argument to be made for specifying nested types in order to define protocol-specific enums especially. The only question really is whether support for sub-modules will overlap, and which is the better solution; nested types would have an advantage of being simple and intuitive though. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
