Proposal: Namespaces


(TJ Usiyan) #1

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.


(James Campbell) #2

Some of this currently is being hacked into the language via the use of
structs.

···

On Fri, Dec 11, 2015 at 10:39 AM, T.J. Usiyan via swift-evolution < swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
 Wizard
james@supmenow.com
+44 7523 279 698


#3

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


(TJ Usiyan) #4

The use case described in the proposal and your response doesn't use
structs as a "bucket of values". I uses *the type* as a bucket of values.
The point of using an empty enum is to emphasize this point. The overal
point of this proposal is to introduce semantics that obviate the need to
'decide' between enum and struct since neither are the type actually
desired. I suggest using an enum as the implementation with the hope that
it will simplify implementation.

Your suggestion of `static struct` emphasizes the utility of a namespace
keyword. Is `static struct …` a declaration of a type or an instance and of
what?

TJ

···

On Sun, Dec 13, 2015 at 6:44 PM, Cole Kurkowski <crk@fastmail.com> 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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Marc Knaup) #5

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@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@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@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


#6

Wouldn't that require a global variable to retain the object? I'm not sure that sounds ideal, since the whole point here is to stay away from having global variables flying around. (Though obviously one instead of N isn't too bad)

I must admit I like your ideal better than namespace as a keyword, though I'm still not completely sold on bringing in anonymous objects to Swift.

···

On Dec 13, 2015, at 17:49, Marc Knaup <marc@knaup.koeln> wrote:

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@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@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@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


#7

100% agree that using a struct this way is far from ideal. I just don't think the problem here is realistically that big of a deal.

If there were major performance gains to be had from the compiler knowing a data structure was essentially a set of grouped constants, then I would completely support adding a keyword to indicate such. I don't believe that's the case though, as it stands I believe both your proposal and my alternative are just syntactic sugar with the potential for confusion.

···

On Dec 13, 2015, at 18:16, T.J. Usiyan <griotspeak@gmail.com> wrote:

The use case described in the proposal and your response doesn't use structs as a "bucket of values". I uses *the type* as a bucket of values. The point of using an empty enum is to emphasize this point. The overal point of this proposal is to introduce semantics that obviate the need to 'decide' between enum and struct since neither are the type actually desired. I suggest using an enum as the implementation with the hope that it will simplify implementation.

Your suggestion of `static struct` emphasizes the utility of a namespace keyword. Is `static struct …` a declaration of a type or an instance and of what?

TJ

On Sun, Dec 13, 2015 at 6:44 PM, Cole Kurkowski <crk@fastmail.com> 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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Marc Knaup) #8

No, an object declaration is a type and an instance at the same time.

Whatever the syntax is, something like `object NotificationNames {}` can be
referred to as type and as instance. It's initialized on first access.
So it's just `NotificationNames.userDataChanged` to access a property and
you can even omit the `static` for all variables.

···

On Mon, Dec 14, 2015 at 2:19 AM, Cole Kurkowski <crk@fastmail.com> wrote:

Wouldn't that require a global variable to retain the object? I'm not sure
that sounds ideal, since the whole point here is to stay away from having
global variables flying around. (Though obviously one instead of N isn't
too bad)

I must admit I like your ideal better than namespace as a keyword, though
I'm still not completely sold on bringing in anonymous objects to Swift.

On Dec 13, 2015, at 17:49, Marc Knaup <marc@knaup.koeln> wrote:

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@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@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@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


(David Owens II) #9

What’s the status on this? Is someone willing to write a proper proposal for this?

I just ran into to this yesterday. I have a project has multiple parsers and naturally, there is a need for multiple `Tokenizer` classes. It’s getting a big obnoxious to continue abuse struct/enum for this.

-David

···

On Dec 13, 2015, at 5:31 PM, Cole Kurkowski via swift-evolution <swift-evolution@swift.org> wrote:

100% agree that using a struct this way is far from ideal. I just don't think the problem here is realistically that big of a deal.

If there were major performance gains to be had from the compiler knowing a data structure was essentially a set of grouped constants, then I would completely support adding a keyword to indicate such. I don't believe that's the case though, as it stands I believe both your proposal and my alternative are just syntactic sugar with the potential for confusion.

On Dec 13, 2015, at 18:16, T.J. Usiyan <griotspeak@gmail.com <mailto:griotspeak@gmail.com>> wrote:

The use case described in the proposal and your response doesn't use structs as a "bucket of values". I uses *the type* as a bucket of values. The point of using an empty enum is to emphasize this point. The overal point of this proposal is to introduce semantics that obviate the need to 'decide' between enum and struct since neither are the type actually desired. I suggest using an enum as the implementation with the hope that it will simplify implementation.

Your suggestion of `static struct` emphasizes the utility of a namespace keyword. Is `static struct …` a declaration of a type or an instance and of what?

TJ

On Sun, Dec 13, 2015 at 6:44 PM, Cole Kurkowski <crk@fastmail.com <mailto:crk@fastmail.com>> 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@swift.org <mailto:swift-evolution@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@swift.org <mailto: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


(Félix Cloutier) #10

I would love it if enums could be backed by any struct type, which I think would solve this specific problem, but it won't be possible before Swift has a model for compile-time-constant expressions.

Félix

···

Le 14 janv. 2016 à 14:34:11, David Owens II via swift-evolution <swift-evolution@swift.org> a écrit :

What’s the status on this? Is someone willing to write a proper proposal for this?

I just ran into to this yesterday. I have a project has multiple parsers and naturally, there is a need for multiple `Tokenizer` classes. It’s getting a big obnoxious to continue abuse struct/enum for this.

-David

On Dec 13, 2015, at 5:31 PM, Cole Kurkowski via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

100% agree that using a struct this way is far from ideal. I just don't think the problem here is realistically that big of a deal.

If there were major performance gains to be had from the compiler knowing a data structure was essentially a set of grouped constants, then I would completely support adding a keyword to indicate such. I don't believe that's the case though, as it stands I believe both your proposal and my alternative are just syntactic sugar with the potential for confusion.

On Dec 13, 2015, at 18:16, T.J. Usiyan <griotspeak@gmail.com <mailto:griotspeak@gmail.com>> wrote:

The use case described in the proposal and your response doesn't use structs as a "bucket of values". I uses *the type* as a bucket of values. The point of using an empty enum is to emphasize this point. The overal point of this proposal is to introduce semantics that obviate the need to 'decide' between enum and struct since neither are the type actually desired. I suggest using an enum as the implementation with the hope that it will simplify implementation.

Your suggestion of `static struct` emphasizes the utility of a namespace keyword. Is `static struct …` a declaration of a type or an instance and of what?

TJ

On Sun, Dec 13, 2015 at 6:44 PM, Cole Kurkowski <crk@fastmail.com <mailto:crk@fastmail.com>> 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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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