[swift-evolution] Proposal: Namespaces

[Marc Knaup]

Sounds like a potential use case for object declarations:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001837.html

Same feature-set as structs but users cannot instantiate it since
namespaces are basically singletons anyway.
Bonus is that you can pass them around and make them conform to protocols.


On Mon, Dec 14, 2015 at 12:44 AM, Cole Kurkowski via swift-evolution <
swift-evolution at swift.org> wrote:

> IMO using  an enum is non-intuitive. A struct is a "bucket of values" and
> so makes fits with the usage here. If the ability to instantiate the
> NotificationNames struct is a problem, adding a
>
> private init()
> {
>
> }
>
> seems more intuitive than co-opting an enum, which has a fairly
> established use case.
>
> Your proposal would essentially be adding a keyword that is transformed
> back into "enum" during compilation. I don't think that a relatively minor
> improvement in clarity for a fairly small use case is worth adding a
> language feature.
>
> Allowing structs to be declared as static would be another way of
> simplifying this kind of declaration, i.e.
>
> static struct NotificationNames {
>      let userDataChanged = ...
>      let recievedAlert = ...
> }
>
> This would allow dropping the private init declaration and dropping the
> static from each property. I'm not sure I think this shortcut is necessary
> or even if it's a good idea, but I do think it fits with the language a
> little better than your current proposal.
>
> On Dec 11, 2015, at 04:39, T.J. Usiyan via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Namespaces
> Author(s): TJ Usiyan
>
> Introduction
>
> A `namespace` keyword for swift hold related global variables.
>
> Motivation
>
> We often want to collect related variables which do not, for whatever
> reason, fit neatly into a type provided by Swift. Importing Objective C
> 'magic strings' as Joshua Sullivan does [here] is one such example. The
> solution he arrives at is a `struct` type with many type variables and no
> fields.
> struct NotificationNames {
>  static let userDataChanged = "UserDataChangedNotificationName"
>  static let receivedAlert = "ReceivedAlertNotificationName"
>  static let peanutButterJellyTime =
> "ItsPeanutButterJellyTimeNotificationName"
> }
>
> Users of this API are not meant to create instances of this type, yet it
> is still possible. A solution to this is to use an `enum` without cases.
>
> enum NotificationNames {
>  static let userDataChanged = "UserDataChangedNotificationName"
>  static let receivedAlert = "ReceivedAlertNotificationName"
>  static let peanutButterJellyTime =
> "ItsPeanutButterJellyTimeNotificationName"
> }
>
> No instances of the `enum` can be made. That this inability to create an
> instance is intentional is only conveyed via the type system.
>
> Proposed solution
>
> Clarity would be greatly improved if we could use `namespace` as a synonym
> for an enum with no cases. This would allow us to avoid repetition of
> `static` as well.
>
> namespace NotificationNames {
>  let userDataChanged = "UserDataChangedNotificationName"
>  let receivedAlert = "ReceivedAlertNotificationName"
>  let peanutButterJellyTime = "ItsPeanutButterJellyTimeNotificationName"
> }
>
> Detailed design
>
> Namespaces can be represented in the type system as enums. All variables
> declared in a namespace's scope would be type variables.
>
> Impact on existing code
>
> This is an additive change and, as such, should not break any existing
> code. Though it doesn't matter, this addition could possibly attain ABI
> compatibility if namespaces are represented as enums without cases.
>
> Alternatives considered
>
> Don't implement namespaces. Developers could continue(begin?) using an
> empty enum to hold type variables.
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> 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/20151214/5bd7ec06/attachment.html>