As in Swift 3 ErrorType has been named to Error, it conflicts with your internal Error class and so if I want to create my own Error enum as follows I get an ambiguous error from the debugger.
public enum UserServiceError: Error {
case UnableToRetrieveUser
case UnableToCreateUser
case UnableToParseUser
case NoCurrentUser
}
Please rename your internal Error.
We LOVE to help with any issues or bugs you have!
Questions: If you have questions about how to use Realm, ask on
StackOverflow.
We monitor therealmtag.Feature Request: Just fill in the first two sections below.
Bugs: To help you as fast as possible with an issue please describe your issue
and the steps you have taken to reproduce it in as many details as possible.Thanks for helping us help you! :-)
Please remove this line and all above before submitting.
Goals
What do you want to achieve?
What did you expected to happen?
What did happened instead?
e.g. the stack trace of a crash
What are steps we can follow to reproduce this issue?
Provide a code sample or test case that highlights the issue.
If relevant, include your model definitions.
For larger code samples, links to external gists/repositories are preferred.
Alternatively share confidentially via mail to [email protected].
Full Xcode projects that we can compile ourselves are ideal!
In the CONTRIBUTING guidelines, you will find a script,
which will help determining these versions.
Realm version: ?
Xcode version: ?
iOS/OSX version: ?
Dependency manager + version: ?
You can avoid the ambiguity by qualifying the base class with a module name. In your case, that'd be by specifying the base class as Swift.Error.
Thanks for the fast response! Did not see that, my mistake.
My take on this is that since the Swift standard library makes use of many standard terms, conflicts will inevitably arise between types it provides and types provided in third-party frameworks. Module namespaces provide a way around this that's cleaner than prefixes on type names like in Objective-C, or giving types unnatural names to avoid conflicts. I'm not sure how others feel about this though.
Most helpful comment
My take on this is that since the Swift standard library makes use of many standard terms, conflicts will inevitably arise between types it provides and types provided in third-party frameworks. Module namespaces provide a way around this that's cleaner than prefixes on type names like in Objective-C, or giving types unnatural names to avoid conflicts. I'm not sure how others feel about this though.