I am not sure if this has been pitched before - a quick search shows something similar, but 3+ years old (from what I understand I should not resurrect old topics) and are focused on modules rather than what I have in mind.
With more complex implementations, I usually tend to break up the implementation into multiple files (rather then scrolling through several thousand lines of code) and usually implement a fair amount of helper structs/classes/enums that help with the complexity of the code, but usually are not needed in the entire project/module, so it's always convenient to declare them under the core class. Example:
File A:
class MyIncrediblyComplexManager {
// Various functionality.
}
File B:
extension MyIncrediblyComplexManager {
struct DataSortingHelper { ... }
enum DataSortingOptions { ... }
}
And so on.
The issue I am having with this is the additional unnecessary indentation. Generally the entire file is unnecessarily indented.
What I'm proposing is full name/qualifier declarations, something like:
struct MyIncrediblyComplexManager.DataSortingHelper {
func sort() { ... }
}
As it's currently possible to do:
extension MyIncrediblyComplexManager.DataSortingHelper {
}
To me this seems that it would be less like a new feature rather than more consistence in the language.
I fully understand that introducing submodules and namespaces could solve this in a way, I don't think that will be any time soon and IMHO focuses on something else - splitting a project into namespaces and submodules is a bit different than allowing full qualifiers in struct/class/enum declarations...
35 Likes
Just for comparison, the Lean programming language allows this as well: a declaration with name A.B declares B in namespace A. And AFAIK this hasn't caused any conceptual problems.
2 Likes
truppelito
(Alexandre Truppel)
3
That's a +1 from me. I do similar stuff all the time and this feature would be a nice bonus.
+1 Anything that promotes proper scoping without increasing the depth of indentations is a good thing in my book.
1 Like
gnuoyd
(David Young)
5
I would get a lot of mileage out of that.
I would love to save a level of indentation on functions, too:
func MyIncrediblyComplexManager.DataSortingHelper.sort() {
...
}
Dave
3 Likes
I like this idea — it's a small but nice change.
Here's an alternative syntax that might be more clear:
extension struct MyIncrediblyComplexManager.DataSortingHelper { ... }
extension func MyIncrediblyComplexManager.DataSortingHelper.sort() { ... }
1 Like
Awesome! I think this is a wonderful idea that should be considered for Swift evolution!
1 Like
Coincidently, today, I created Codable types nested up to about 5 levels and did not feel too happy about it. I would definitely use this feature!
1 Like
davdroman
(David Roman)
10
I'm strongly +1 on this.
On a side note, I feel this post is not receiving the attention it deserves. Maybe changing the title to something more descriptive might help.
e.g. "[Pitch] Allow dot-syntax qualifiers in declarations".
4 Likes
tera
11
+1
If to do it for types & functions maybe also do it for all other things that are allowed in extensions, like variables with getters / setters & static variables?
var MyIncrediblyComplexManager.DataSortingHelper.foo: String {
"Hello, World"
}
static var MyIncrediblyComplexManager.DataSortingHelper.foo: Int = 123
Saklad5
(Jeremy Saklad)
12
+1
This is a very simple change, but a very useful one: namespacing is an important part of concise code, and this should encourage names that take advantage of it.
tera
13
Perhaps this as well:
typealias Foo.Bar.Baz = Qux
as a shorthand for
extension Foo.Bar {
typealias Baz = Qux
}
3 Likes
