<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>On Fri, Dec 11, 2015, at 02:39 PM, Douglas Gregor wrote:<br></div>
<blockquote type="cite"><div> </div>
<div><blockquote type="cite"><div>On Dec 11, 2015, at 1:19 PM, Kevin Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div>
<div> </div>
<div><div>I've now submitted this proposal as a PR: <a href="https://github.com/apple/swift-evolution/pull/50">https://github.com/apple/swift-evolution/pull/50</a><br></div>
</div>
</blockquote><div> </div>
<div>Thanks for writing this up!<br></div>
<div> </div>
<div>I was actually surprised that this didn’t already work; @objc is supposed to be able to rename effectively anything at this point. Given that, and that another core team member has already +1’d, we can skip the evolution process and call this a bug fix. Want to contribute a fix?<br></div>
</div>
</blockquote><div> </div>
<div>I'd love to! I'll start working on one over the weekend.</div>
<div> </div>
<blockquote type="cite"><div><blockquote type="cite"><div><div><div>I listed one open question:<br></div>
<div> </div>
<div>Should the generated Obj-C declarations use the swift_name attribute to indicate the Swift type it came from? Proposal SE-0005 generalizes swift_name to apply to any arbitrary C or Obj-C entity, so it will be legal to put on enums.<br></div>
<div> </div>
<div>Labelling it makes it clear to the reader what the Swift equivalent is, but I'm unsure if there's any downsides to doing this.<br></div>
</div>
</div>
</blockquote><div> </div>
<div>Yes, it makes sense to use the swift_name attribute here. If you’re implementing your proposal, check out lib/PrintAsObjC/PrintAsObjC.cpp and how we use the SWIFT_COMPILE_NAME macro for this in the generated header.<br></div>
</div>
</blockquote><div> </div>
<div>Will do. My worry with using swift_name is that, at least in the clang that ships with Xcode 7.2, you can't actually put the swift_name attribute on an enum. I assume that will change with SE-0005, but I also assume this hasn't been implemented yet. And even when it is implemented, emitting it will be a backwards-compatibility hazard if the generated header needs to work with older clangs. Is there any way to suppress the error?<br></div>
<div> </div>
<div>I'm also not sure offhand where you actually put the attribute on an enum, since the enum definition is actually 2 declarations, one for the typedef and one for the enum itself. Would it go after the `enum` keyword, in the place where SWIFT_ENUM_EXTRA is?<br></div>
<div> </div>
<div>-Kevin Ballard</div>
</body>
</html>