[swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism

Haravikk swift-evolution at haravikk.me
Thu Jun 30 14:57:25 CDT 2016


> On 30 Jun 2016, at 11:22, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
> It is an interesting suggestion to use extensions that way, but how would you nest and create diffrent label pathes with extensions? 
> 
> We also cannot nest extensions (yet) and when it comes to conformances the access modier is not allowed on extensions. That is one of my points to remove this behavior from extensions and have equal access contol on extensions like on classes etc.!

How about just allowing more periods in the naming? Like so:

	struct A {}
	public extension A.foo {
		func someMethod() { … } // a.foo.someMethod()
	}
	private extension A.foo.bar {
		func someHiddenMethod() { … } // a.foo.bar.someHiddenMethod() 
	}

	// Alternatively:
	extension A {
		public func foo.someMethod() { … }
		private func foo.bar.someHiddenMethod() { … }
	}

I suppose it lacks the kind of visual hierarchy that grouping within the type could achieve, but at the same time such grouping could get unwieldy quickly due to implementation details growing the vertical height until the structure becomes unclear. This is why I'd favour extensions personally. There could still be call for both though, as a balance such as simple properties and methods declared hierarchically within the type, vs large methods moved out into extensions, letting us mix and match however we like. I do think that the extension one should be considered though, as it's a recommended way to handle code structure in Swift I think, or at least I'm addicted to using it ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160630/0ca142a0/attachment.html>


More information about the swift-evolution mailing list