[Pitch] Full name identifiers

Evolution Pitches
1

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
2

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
3

That's a +1 from me. I do similar stuff all the time and this feature would be a nice bonus.

4

+1 Anything that promotes proper scoping without increasing the depth of indentations is a good thing in my book.

1 Like
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
6

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
7

Awesome! I think this is a wonderful idea that should be considered for Swift evolution!

1 Like
8

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
9

+1

1 Like
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
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
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.

13

Perhaps this as well:

typealias Foo.Bar.Baz = Qux

as a shorthand for

extension Foo.Bar {
    typealias Baz = Qux
}
3 Likes
14

+1

15

+1