search

dropbox / djinni

A tool for generating cross-language type declarations and interface bindings.
Apache License 2.0
2.88k stars 488 forks source link

Generated closed enums to better interop with Swift #437

Closed 4brunu closed 5 years ago

4brunu commented 5 years ago

This PR intents to enhance the Swift 5 and generated objc interoperability in Enums.

Before Swift 5, all C enums were closed, but in Swift 5 they become open by default in an effort to prepare Swift for binary compatibility.

This is useful for third party code, but since djinni is used to generate the bridge between objc and c++ inside an app and all the code, written on generated are controlled inside the teams responsible by them, all enums should be closed by default.

https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md

EDIT: IF you prefer I can introduce a new flag, to choose between closed or open enums, although I think the closed enums will almost always be the preferred option, since it's the default Swift enums option, and Swift has safety features that works best with closed enums.

artwyman commented 5 years ago

Closed vs. open does seem like it would be a developer choice in theory, based on whether they need to support future binary-compatible extensions of their API. I agree that most devs will want closed by default.

Regardless, though, this repo isn't going to be adding any new features so I'm putting this PR on hold.

4brunu commented 5 years ago

What if we introduce a new flag, to choose between closed or open enums?

artwyman commented 5 years ago

I think a new cmdline flag is a good workaround for potential breaking changes, so I'd be willing to merge that. This might even be the kind of thing which could be represented by a new sort of deriving, but that might be overkill

4brunu commented 5 years ago

@artwyman I added a command line argument for avoiding breaking changes.