<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">What’s the status on this? Is someone willing to write a proper proposal for this?<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">-David</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 13, 2015, at 5:31 PM, Cole Kurkowski via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">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. </div><div class=""><br class=""></div><div class="">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 <b class="">and</b> my alternative are just syntactic sugar with the potential for confusion.</div><div class=""><br class="">On Dec 13, 2015, at 18:16, T.J. Usiyan <<a href="mailto:griotspeak@gmail.com" class="">griotspeak@gmail.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">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.<div class=""><br class=""></div><div class="">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? </div><div class=""><div class=""><br class=""></div><div class="">TJ</div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sun, Dec 13, 2015 at 6:44 PM, Cole Kurkowski <span dir="ltr" class=""><<a href="mailto:crk@fastmail.com" target="_blank" class="">crk@fastmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class="">IMO using <span style="background-color:rgba(255,255,255,0)" class=""> 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 </span></div><div class=""><br class=""><div class=""><span style="background-color:rgba(255,255,255,0)" class="">private init() </span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class="">{</span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class=""><br class=""></span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class="">}</span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class=""><br class=""></span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class="">seems more intuitive than co-opting an enum, which has a fairly established use case. </span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class=""><br class=""></span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class="">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.</span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class=""><br class=""></span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class="">Allowing structs to be declared as static would be another way of simplifying this kind of declaration, i.e.</span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class=""><br class=""></span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class="">static struct NotificationNames {</span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class=""> let userDataChanged = ...</span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class=""> let recievedAlert = ...</span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class="">}</span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class=""><br class=""></span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class="">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. </span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class=""><br class=""></span></div></div><div class=""><div class="h5"><div class="">On Dec 11, 2015, at 04:39, T.J. Usiyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div></div></div><blockquote type="cite" class=""><div class=""><div class=""><div class="h5"><div dir="ltr" class=""><div class="">Namespaces</div><div class="">Author(s): TJ Usiyan</div><div class=""><br class=""></div><div class="">Introduction</div><div class=""><br class=""></div><div class="">A `namespace` keyword for swift hold related global variables.</div><div class=""><br class=""></div><div class="">Motivation</div><div class=""><br class=""></div><div class="">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.</div><div class=""><span style="white-space:pre-wrap" class=""> </span></div><div class=""><span style="white-space:pre-wrap" class=""> </span>struct NotificationNames {</div><div class=""><span style="white-space:pre-wrap" class=""> </span> static let userDataChanged = "UserDataChangedNotificationName"</div><div class=""><span style="white-space:pre-wrap" class=""> </span> static let receivedAlert = "ReceivedAlertNotificationName"</div><div class=""><span style="white-space:pre-wrap" class=""> </span> static let peanutButterJellyTime = "ItsPeanutButterJellyTimeNotificationName"</div><div class=""><span style="white-space:pre-wrap" class=""> </span>}</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class=""><span style="white-space:pre-wrap" class=""> </span>enum NotificationNames {</div><div class=""><span style="white-space:pre-wrap" class=""> </span> static let userDataChanged = "UserDataChangedNotificationName"</div><div class=""><span style="white-space:pre-wrap" class=""> </span> static let receivedAlert = "ReceivedAlertNotificationName"</div><div class=""><span style="white-space:pre-wrap" class=""> </span> static let peanutButterJellyTime = "ItsPeanutButterJellyTimeNotificationName"</div><div class=""><span style="white-space:pre-wrap" class=""> </span>}</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Proposed solution</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class=""><span style="white-space:pre-wrap" class=""> </span>namespace NotificationNames {</div><div class=""><span style="white-space:pre-wrap" class=""> </span> let userDataChanged = "UserDataChangedNotificationName"</div><div class=""><span style="white-space:pre-wrap" class=""> </span> let receivedAlert = "ReceivedAlertNotificationName"</div><div class=""><span style="white-space:pre-wrap" class=""> </span> let peanutButterJellyTime = "ItsPeanutButterJellyTimeNotificationName"</div><div class=""><span style="white-space:pre-wrap" class=""> </span>}</div><div class=""><br class=""></div><div class="">Detailed design</div><div class=""><br class=""></div><div class="">Namespaces can be represented in the type system as enums. All variables declared in a namespace's scope would be type variables.</div><div class=""><br class=""></div><div class="">Impact on existing code</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Alternatives considered</div><div class=""><br class=""></div><div class="">Don't implement namespaces. Developers could continue(begin?) using an empty enum to hold type variables.</div></div>
</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" class="">
</div></blockquote><span class=""><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></span></div></blockquote></div><br class=""></div>
</div></blockquote>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=nE9rxSXA5G4kxsTVkgv43pXkLx-2B36P-2BPNJufHeY0dgf7fifYz7IbPvatxlOapCituqsrQYuBFgNbuqtOOxg1JAtVdRyFBhLreSWKma-2BN6STc-2FGLvvT5pHb9Dz3wQi7f2aXWSogm9pAiKFB1clOgCqjWhgNaxHsJvrEM4mFSXnIZLclJMxmFk4PJCj4dShRHMXoH9CNNtkqmsdOCK1mEdSg-3D-3D" alt="" width="1" height="1" border="0" style="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;" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>