`namespace` keyword

[Chris_Lattner3 (Chris Lattner)]

@vmartinelli

I can imagine the conversation:

— We have real namespaces, abstract classes, protected methods, LINQ, async, await and many other things. And you? — said the C# guy.

— Well… We have fear. We have much fear from adding new keywords to our loved language — replied the passionated Swift programmer and forum activist.

— But… You still can add to numbers using ++, right?

I know you're joking, but ++ was a bad idea even for C#. Just saying.

-Chris

[vmartinelli (Vanderlei Martinelli)]

@Chris_Lattner3 Well... I think you program in Swift since the day zero. ;)

OK. We do not need ++ anyway. But do we can have a keyword for namespaces? Please...?

(Since I think having async and await in Swift is now a matter of time.)

Without adulation and jokes aside, thank you for bringing us this language that is indeed very enjoyable to code.

[felix91gr (Félix Fischer)]

@vmartinelli

So… I can still be ironic, right?

Of course, but bear in mind that C# more than doubles Swift in age. Many of its niceties only started coming along on the roundabouts of C# 4.0, if I’m not misremembering. And without a yearly cycle, that took a while as well.

[felix91gr (Félix Fischer)]

@anandabits

The primary goal of submodules (IMO) is to separate the logical structure and encapsulation afforded by modules from the physical structure (and associated overhead) of a build product.

I find submodules very interesting. I’m looking forward to when we have this discussion

[gwendal.roue (Gwendal Roué)]

When you write documentation, you sometimes want to provide a canonical and recommended way to achieve a goal. But practically speaking, you can't provide canonical code that contains namespace enums, even if you know that this is the best solution for the discussed problem:

Namespace enums look foreign in the mind of readers who are not familiar with the pattern. They try to find how the enum fits in the topic. They look for cases that do not exist. They lose track of the main documented topic. And induced cognitive dissonance is a sign of documentation failure.

I thus totally understand how namespace enums are enough, coding-wise. But they are less than ideal, communication-wise.

[taylorswift]

absolutely yes! my idea of submodules is basically a type of namespace that can be shipped by the package manager. But unlike a module, it would have no ABI boundaries, the entire namespace of code would be internal to the importing module.

[taylorswift]

@gwendal.roue

When you write documentation, you sometimes want to provide a canonical and recommended way to achieve a goal. But practically speaking, you can’t provide canonical code that contains namespace enums, even if you know that this is the best solution for the discussed problem:

Namespace enums look foreign in the mind of readers who are not familiar with the pattern. They look for cases that do not exist. They lose track of the main documented topic. And induced cognitive dissonance is a sign of documentation failure.

I thus totally understand how namespace enums are enough, coding-wise. But they are less than ideal, communication-wise.

idk it didn’t take me that long to figure that out when i first learned this language. this is the kind of pattern you teach once and it never becomes confusing again tbh

[gwendal.roue (Gwendal Roué)]

@taylorswift

idk it didn’t take me that long to figure that out when i first learned this language. this is the kind of pattern you teach once and it never becomes confusing again tbh

I do not write documentation for you only.

[vmartinelli (Vanderlei Martinelli)]

@taylorswift But this is also my point. If enum has this behaviour, we need this documented and guaranteed to work in the future (or near future at least).

[taylorswift]

@gwendal.roue

i do not write documentation for you only.

unless you’re writing tutorials i would assume the target audience of your documentation would have enough experience with Swift to have learned this pattern too

[gwendal.roue (Gwendal Roué)]

@taylorswift

unless you’re writing tutorials i would assume the target audience of your documentation would have enough experience with Swift to have learned this pattern too

I don't know if you write documentation or not. I you do, make an experiment. If you don't, please accept that my experience may differ from your intuition.

[taylorswift]

@vmartinelli

@taylorswift But this is also my point. If enum has this behaviour, we need this documented and guaranteed to work in the future (or near future at least).

enums doubling as namespaces aren’t just a convenient by-product of an implementation detail. it comes from the fact that all Swift types also come with their own namespaces. This is fundamental to Swift’s typing and access-control model.

[vmartinelli (Vanderlei Martinelli)]

I know. And I know that many types in Swift can double as namespaces. But in the specific enum case, as @gwendal.roue said, imagine how one says this in the official documentation. "We can create enumerations and namespaces using enum."

[taylorswift]

@gwendal.roue

I don’t know if you write documentation or not. I you do, make an experiment. If you don’t, please accept that my experience may differ from your intuition.

I do write documentation. and so does the standard library team.

[gwendal.roue (Gwendal Roué)]

I'm not in the standard library team, unfortunately.

And I did not intend to diminish your contributions.

My intention was to bring experience. I not only write reference documentation, but also high-level guides that globally address some use cases. It just happens that I had user feedback that had me rewrite some sample code. Namespace enums sometimes just divert the reader's mind from the discussed topic. When this happens, I don't tell the user that he should know more: I fix the documentation so that it fulfills its communication job.

(Actually, I thank the user for his feedback, then do tell the user about namespace enums, and finally fix the documentation so that other users are not confused)

[gwendal.roue (Gwendal Roué)]

@taylorswift

I do write documentation. and so does the standard library team.

I think that you did provide links to documentations of namespace enums, in an attempt at proving that they can be documented. Yes namespace enums exist, yes they do the job, yes a Swift developer eventually has to meet them. I totally agree.

But this wasn't really my point.

I was trying to say that namespace enums in canonical sample code (not in the library code) are not the documentation-writer friend. It's difficult to give users an advice such as "it is recommended to group those declarations in a namespace enum". That is because when you write documentation, it's dangerous:

• to introduce two topics at the same time: your main topic, and namespace enums.
• to provide sample code that is ambiguous: the enum keyword is usually followed by cases, in Swift. When it isn't, the risk of inducing dissonance in the reader's mind is high. Even when the reader is an experienced developer!

[Tino]

@cal

Swift already has atleast 103 keywords

... and that's although they try hard to keep the number low - afair, in in closures was chosen because of for x in collection already existed ;-)

I'm still dislike the "enum hack", but I'm also still skeptical that namespace carries its own weight.
Imho that concept needs more power to justify a new keyword, but its unclear how to achieve this.

namespace could be used to modify some language defaults (like you can do with public extension), but I don't have any good use cases for that.

It might be really nice to utilize namespaces in access control - but that whole topic is scorched earth, and we'll probably have to live forever with what we have now.

So, what else besides changing how to specify its members could namespace do for us?

[taylorswift]

@Tino

namespace could be used to modify some language defaults (like you can do with public extension), but I don’t have any good use cases for that.

can you like explain exactly why this would specifically be useful? I thought all swift types limit the maximum visibility of their members.

as for extension access modifiers,, i never liked this part of the language and i always thought it was weird this is a warning and not an error

public 
struct S {}

private 
extension S 
{
    public 
    func f() {}
}

[Tino]

@taylorswift

can you like explain exactly why this would specifically be useful?

As I wrote ;-): I don't have a use case that could not easily be considered harmful... but I'd be happy if someone else has a cool enhancement for namespace:
Without something on top, imho this discussion will lead to nowhere.

[dlbuckley (Dale Buckley)]

I use the enum method quite a bit, but it's biggest flaw is that you can't encapsulate protocol declarations. This limitation makes perfect sense for enum types. Declaring a protocol inside an enum makes no sense and could lead to some confusion as to what an enum should be used for.

I think the biggest argument for namespaces is that you could encapsulate protocols (I know this has been mentioned further up in the thread but I just want to emphasise what difference it would make). It's a very useful tool to have in the toolbox and makes reasoning about the code more self explanatory.

Currently we have this situation:

enum FirstThing { }

extension FirstThing {

    struct MyValue {

        let something: FirstThingMyProtocol
    }
}

protocol FirstThingMyProtocol { }

let firstValue: FirstThingMyProtocol

With a namespace we could have:

namespace SecondThing { }

extension SecondThing {

    struct MyValue {

        let something: MyProtocol
    }

    protocol MyProtocol { }
}

let secondValue: SecondThing.MyProtocol

In the end there isn't a "need" for a namespace, what we want to do could be done right now with the enum like a lot of people are saying. But in terms of being able to clean up code it's a good tool to be able to organise and make code easier to reason about.

I dont know if it would make any difference as the compiler isn't really my strong point, but could namespace also be used to help the compiler reason about the code encapsulated inside?