[swift-evolution] [Pitch] Custom Namespaces

[Andrey Tarantsov]

Yeah, I'd say the namespaces should take a form of submodules, possibly defined by subdirectories or something like that. I.e. not defined explicitly in code.

A.


> On Apr 2, 2016, at 5:15 AM, Howard Lovatt via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Yes something in this space might be useful, but, and this is a significant but, we do have modules and files to break code into. So it wouldn't be a top priority.
> 
> On Wednesday, 30 March 2016, Niels Andriesse via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> At the moment, it's not possible to define custom namespaces. They can be emulated using static members on an enum:
> 
> enum Foo {
>   static var bar: Bar
>   static func baz() { }
> }
> 
> This is not ideal, because:
> The case shown above is semantically speaking obviously not an enum and shouldn't be presented as such.
> The members are required to be static unnecessarily.
> Not all top-level declarations can be nested like this (e.g. protocols).
> If we allow namespaces to be reused in different files within the same module, this could potentially be used as a custom scope for access control (e.g. using the proposed private(...) syntax, so in this case private(Foo)).
> Are there any plans to allow custom namespaces (for example as shown below)?
> 
> namespace Foo {
>   var bar: Bar
>   func baz() { }
> }
> 
> Alternatively, a similar situation could be achieved by introducing submodules.
> 
> 
> -- 
> -- Howard.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160403/9bbf4abe/attachment.html>