<div dir="ltr">Some of this currently is being hacked into the language via the use of structs.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 11, 2015 at 10:39 AM, T.J. Usiyan 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="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=xV0JY-2FdZMnUMvSFtZnLiBPRTDDOSQf3-2FpH33HYOlBxGt7-2FicXL6yp9wh-2BLgQW90G6rQbmVZ-2BZaTO8QhZ-2F2kwF26iVNbJVXflbeOfF0J7Cc4GIhKH9FeADhPsRglOKlpzEBtTw0OT6M4ynWK6V63qA-2BbxrlAPGVoE2doIw4Dn-2BQUTibf-2FqfuwFhsTVWp-2FI37hAWUTtHiL-2FhdezOBIG2G7L3E8IlZRpgBJtevDpW74TO4-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">
<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><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div><span style="font-size:16px;line-height:19.2px"></span><span style="font-size:12.8px"> Wizard</span><br></div><div><a href="mailto:james@supmenow.com" target="_blank">james@supmenow.com</a></div><div>+44 7523 279 698</div></div></div></div></div></div>
</div>