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@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@swift.org <mailto:swift-evolution@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
