<div dir="ltr">Sounds like a potential use case for object declarations:<div><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001837.html">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001837.html</a><br></div><div><br></div><div>Same feature-set as structs but users cannot instantiate it since namespaces are basically singletons anyway.</div><div>Bonus is that you can pass them around and make them conform to protocols.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 14, 2015 at 12:44 AM, Cole Kurkowski via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>IMO using <span style="background-color:rgba(255,255,255,0)"> an enum is non-intuitive. A struct is a &quot;bucket of values&quot; and so makes fits with the usage here. If the ability to instantiate the NotificationNames struct is a problem, adding a </span></div><div><br><div><span style="background-color:rgba(255,255,255,0)">private init() </span></div><div><span style="background-color:rgba(255,255,255,0)">{</span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">}</span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">seems more intuitive than co-opting an enum, which has a fairly established use case. </span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">Your proposal would essentially be adding a keyword that is transformed back into &quot;enum&quot; during compilation. I don&#39;t think that a relatively minor improvement in clarity for a fairly small use case is worth adding a language feature.</span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">Allowing structs to be declared as static would be another way of simplifying this kind of declaration, i.e.</span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">static struct NotificationNames {</span></div><div><span style="background-color:rgba(255,255,255,0)">     let userDataChanged = ...</span></div><div><span style="background-color:rgba(255,255,255,0)">     let recievedAlert = ...</span></div><div><span style="background-color:rgba(255,255,255,0)">}</span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">This would allow dropping the private init declaration and dropping the static from each property. I&#39;m not sure I think this shortcut is necessary or even if it&#39;s a good idea, but I do think it fits with the language a little better than your current proposal. </span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div></div><div><div class="h5"><div>On Dec 11, 2015, at 04:39, T.J. Usiyan via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div>Namespaces</div><div>Author(s): TJ Usiyan</div><div><br></div><div>Introduction</div><div><br></div><div>A `namespace` keyword for swift hold related global variables.</div><div><br></div><div>Motivation</div><div><br></div><div>We often want to collect related variables which do not, for whatever reason, fit neatly into a type provided by Swift. Importing Objective C &#39;magic strings&#39; 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.</div><div><span style="white-space:pre-wrap">        </span></div><div><span style="white-space:pre-wrap">        </span>struct NotificationNames {</div><div><span style="white-space:pre-wrap">        </span>  static let userDataChanged = &quot;UserDataChangedNotificationName&quot;</div><div><span style="white-space:pre-wrap">        </span>  static let receivedAlert = &quot;ReceivedAlertNotificationName&quot;</div><div><span style="white-space:pre-wrap">        </span>  static let peanutButterJellyTime = &quot;ItsPeanutButterJellyTimeNotificationName&quot;</div><div><span style="white-space:pre-wrap">        </span>}</div><div><br></div><div>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. </div><div><br></div><div><span style="white-space:pre-wrap">        </span>enum NotificationNames {</div><div><span style="white-space:pre-wrap">        </span>  static let userDataChanged = &quot;UserDataChangedNotificationName&quot;</div><div><span style="white-space:pre-wrap">        </span>  static let receivedAlert = &quot;ReceivedAlertNotificationName&quot;</div><div><span style="white-space:pre-wrap">        </span>  static let peanutButterJellyTime = &quot;ItsPeanutButterJellyTimeNotificationName&quot;</div><div><span style="white-space:pre-wrap">        </span>}</div><div><br></div><div>No instances of the `enum` can be made. That this inability to create an instance is intentional is only conveyed via the type system. </div><div><br></div><div>Proposed solution</div><div><br></div><div>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.</div><div><br></div><div><span style="white-space:pre-wrap">        </span>namespace NotificationNames {</div><div><span style="white-space:pre-wrap">        </span>  let userDataChanged = &quot;UserDataChangedNotificationName&quot;</div><div><span style="white-space:pre-wrap">        </span>  let receivedAlert = &quot;ReceivedAlertNotificationName&quot;</div><div><span style="white-space:pre-wrap">        </span>  let peanutButterJellyTime = &quot;ItsPeanutButterJellyTimeNotificationName&quot;</div><div><span style="white-space:pre-wrap">        </span>}</div><div><br></div><div>Detailed design</div><div><br></div><div>Namespaces can be represented in the type system as enums. All variables declared in a namespace&#39;s scope would be type variables.</div><div><br></div><div>Impact on existing code</div><div><br></div><div>This is an additive change and, as such, should not break any existing code. Though it doesn&#39;t matter, this addition could possibly attain ABI compatibility if namespaces are represented as enums without cases.</div><div><br></div><div>Alternatives considered</div><div><br></div><div>Don&#39;t implement namespaces. Developers could continue(begin?) using an empty enum to hold type variables.</div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=-2Bxb47WeGoqMoAgzLM1ObomDZ33eAoWUyfgnPK0aY0kmOBV0UOL-2F-2FewTnMlFakhgehvwInLhXqOSgLWhWSC59AspLa6GqGYZeh-2BtdIo20WyqWuINj3rtuE9qLd-2BiL4jagc5HtjH2Ce0ulfeDXCmavB061BWZFQBdbt3RewD1Vr7Qm8vt6InljqJC-2FSC7yR9nSfTzLs3qbGWpKpC-2BzjutEtkq79cco-2BGmJif1-2BbbIwACs-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</div></blockquote></div></div><blockquote type="cite"><div><span>_______________________________________________</span><span class=""><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></span></div></blockquote>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=6ZGE61OxINd5lLe2xYh9Ku-2BXbixWNr2nvfzp2IB1sZgO93S0GjF-2FBLbNsjiS9bZCN6qivxY-2FMQm88297IFwucGKKnMPcpjI6abX5QU0DLTv2n2Sh-2FWurt7-2Fwo4VIFzKYo9Nps0yZEycNRrWJGYfDQp0CSUof-2FuBWp0Isvut2JnEF6b1q-2Bb6GO0Aqdz0Y-2FRTZiHlmHMC4KZOhk-2Bz9jh5uPLB-2FNFGMduTX-2BUib-2FgoLMYA-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</div>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>