i completely agree!! that being said,, out of all the things that need fixing in Swift this seems like the least concern to me considering we already have a perfectly valid (except for protocols), , and widely used, , solution to the problem that people in this thread don’t like because they want to write the word “namespace” instead of “enum”
Agreed. Submodules are out of scope for now and should come before any consideration of namespaces. The enum workaround is perfectly acceptable in the meantime.
5 Likes
@taylorswift Your arguments about Swift types doubling as namespaces make sense and I agree with them (although I still prefer using namespace when enum is not semantically the first choice).
@anandabits I think that enum workaround is acceptable only if there is a guarantee that empty enum posing as namespace is a "feature" documented and supported in future versions of Swift. Otherwise, we will have to rewrite our code again as we have done in recent years. I think if we can have a bool toggle we can also have the inclusion of the namespace keyword. No harm for anyone at all.
On a few occasions, I’ve wished that Swift supported a “singleton” type kind where T.Type == T and T.self was the only instance. (This would imply that there was no static/instance distinction.) Namespaces might be a good form of that.
3 Likes
I can drive nails easily with a big ratchet... nonetheless, I like to have a hammer as well.
Enums just aren't designed to be namespaces, they have their own use case, and it's odd to use them for something completely different.
The only problem I see is that it feels also odd to have an extra keyword just to be able to write "Namespace.myConstant"...
it’s not a feature as much as it is a convention
i agree it reads weird for newcomers but i’d rather overload enum (and make it support nested protocols which currently it does not) than reserve another keyword as a synonym for basically the exact same functionality. i don’t like languages with 24557414 reserved keywords
+1 to this, please! I would love this. Please allow protocols to be nested in the namespace as well. That's something enums can't do.
enum A {
protocol B {}
}
error: MyPlayground.playground:18:14: error: protocol 'B' cannot be nested inside another declaration
protocol B {}
^
3 Likes
If we allow protocols to be defined inside "namespaces" — which I'd really like to happen — I think the opposite should be done as well: be able to define other types inside a protocol "namespace".
protocol AProtocol {
struct AStruct {}
}
1 Like
Imho protocols could be a slightly better namespace-replacement than enum... just not sure what should happen when you conform to such a protocol ;-)
This is also the same idea you included into the metatype proposal back then. I recently thought about something similar where a module would have a storage type with boxes that would have weak references to unique class instances and with the combination of future factory initialisation on classes could have unique references (e.g. UIColor instances are singletons for each different color). Similar approach could work for static metatypes if they were reference types.
IIRC the major issue was that we could't find an agreement what nested types would capture from the outer types (if the protocol was nested into another type, a protocol was nested into another protocol, a type was nested into a protocol, etc.) @karl should know better because it was his pitch back then.
In response to that and to solve some ambiguity I opened a thread in the early days of this forum but no one shared any interest or debunked the idea as complete garbage:
I think this is a great idea!
Using enum as a uninstantiable namespace is clearly an anti-pattern. That use case falls out of the implementation of our enum keyword, and these "namespace" enums have nothing that makes them otherwise "enum-like".
It's clear that these namespaces are a useful feature, considering that using enum in this way has become a common convention. Adding a namespace keyword would let us express this intent in a first-class way instead of abusing a quirk of the language to get the functionality we're looking for.
While at this time it namespace would just be a subset of functionality otherwise available to an enum, it gives us a springboard to implement other features that are useful in the context of a namespace Defining protocols in a namespace comes to mind (not currently possible inside an enum), but it would also be quite nice for functions and variables to automatically be static by default!
3 Likes
Swift already has atleast 103 keywords. Even C++ only has 78.
I say this to mean that I don't think "having a small number of reserved keywords" is a primary goal for the language.
1 Like
and this is a problem. being more complicated than C++ is nothing to brag about
4 Likes
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?
— Hum... Nop!
— Why?
— The Swift Core Team's most loved ones do not like that kind of thing either... But, look! We can toggle our booleans using one method, so we do not need to use the ! operator.
— ?!?!
(Yes, I love Swift too and I also program in Swift since the day zero. I do not want a mess, but I think some things are harder to have in Swift than other languages. And I do not know why. So... I can still be ironic, right?)
6 Likes
Just because there are a large number of keywords, doesn't not mean that we shouldn't consider adding more. If there is a concrete need to add a new keyword, then I believe we should strongly consider them.
That being said, the bar for adding them should be fairly high. Introducing something like async/await or ownership stuff come to mind.
That being said. I'm on the fence about actual namespaces. While it may feel wrong to use a struct or enum to namespace additional types, I've found that this is good enough for my needs.
annalora: Why doesn’t Swift have namespacing?
tree: Well, we use enums for that! All of our type declarations also come with their own scope! Isn’t that convenient?
annalora: but… I don’t want an enum, I want a namespace!
tree: But you see, the enum does the exact same thing as the namespace. So if you want a namespace, just use an enum!
penni: what if I want to nest protocols in an enum…
tree: shut up. that’s an incomplete implementation. Anyways
annalora: I want to be able to write namespace because otherwise I would think my namespace was an instantiable enum type.
tree: And you have no other way of telling?
annalora: Well, if I only had like 4 or 5 namespaces in a project, I guess I could just remember them. But I have dozens and dozens of scopes I want to use in my project.
tree: but would they all go into uninstantiable enums?
annalora: Come to think about it, most of the types and functions I wanted to scope, I scoped to instantiable struct types. Because that code actually related to some concrete object in my program. To be honest, I think I only really use 2 or 3 totally abstract, top-level namespace containers at a time.
tree: so would you agree it’s not worth adding a redundant keyword for something you only do 2 or 3 times a project?
annalora: I didn’t say that. Scooter uses Cee Sharp, and he says everything is easier in Cee Sharp
tree: And how exactly would having a namespace keyword make things easier?
annalora: It’s less typing than enum I guess.
2 Likes
I can see some ABI destabilisation happening here... hahaha ;) I do not want to force and unwrap any optionals, however. (I love Swift more than C#, by the way. And I love all of you. Really.)
1 Like