Changing Realm Swift's Error type to just be a typealias for RLMError

[austinzheng]

There's no real good reason to have Error in Realm Swift be its own separate enum. Having an == for non-specific ErrorProtocol instances is also kind of problematic.

@tgoyne @jpsim @bdash @JadenGeller

[JadenGeller]

+1

Will Jazzy still generate Swift documentation for Error cases?

[austinzheng]

Ugh. Good question, let me try regenerating the docs and see what happens.

[austinzheng]

I wasn't able to get Jazzy working with Xcode 8, but I do know what happens: we won't get the per-case documentation for Error anymore. We may want to move the summary of the error cases into the main documentation, and then add a link.

[JadenGeller]

Aw, that definitely sucks. It's still probably a good move to consolidate these types though, so still +1 from me.

[JadenGeller]

How difficult would it be to extend Jazzy so that "exported" classes also generate documentation? @jpsim

[austinzheng]

I think what I'm going to do is as follows:

• Pull the descriptions for each error case into the online documentation.
• In both the objc and swift bindings, add a link in the type's docstrings to the documentation. (I'll leave the current ObjC per-case documentation in place.)

This is sort of like how the PropertyType alias is documented.

Would anyone have any objections to this?

[JadenGeller]

How does this change interact with the NSError bridging changes in Swift 3? Does this change limit what sort of information we can include with errors in the future (since RLMError is a primitive type)?

[jpsim]

Jazzy doesn't document inherited members, which also includes typealiases. See #190 realm/jazzy#190.

[JadenGeller]

@jpsim Wrong issue number?

[jpsim]

Right issue number, wrong repo: realm/jazzy#190

[austinzheng]

Superseded by #3934, which also debated this issue (and decided it wasn't worth the trouble to implement).