Thoughts on failure() changes

[Rob Napier]

I've made a couple of changes around failure(), with Justin's help:

https://github.com/LlamaKit/LlamaKit/issues/5

https://github.com/LlamaKit/LlamaKit/issues/4

My only concern here is whether it's getting to fancy for the core module, and whether some of this should be considered an add-on or consumer-specific. Here's the rundown:

Based on Brad's input, Result.Failure now takes an abstract ErrorType (which has no protocol requirements) rather than an NSError. NSError conforms to ErrorType. This should make Result much more flexible, at a cost of having to downcast errors if you need to inspect them. I think that flexibility is probably worth it. The downcasting can be easily wrapped into helper functions. So I feel pretty good about this change.

The second change is to make failure() a little friendlier, and this is where I'm getting nervous about feature creep. We now have:

private func defaultError(userInfo: [NSObject: AnyObject]) -> NSError {

  return NSError(domain: "", code: 0, userInfo: userInfo)

}

public func failure<T>(message: String, file: String = __FILE__, line: Int = __LINE__) -> Result<T> {

  let userInfo: [NSObject : AnyObject] = [NSLocalizedDescriptionKey: message, ErrorFileKey: file, ErrorLineKey: line]

  return failure(defaultError(userInfo))

}

public func failure<T>(file: String = __FILE__, line: Int = __LINE__) -> Result<T> {

  let userInfo: [NSObject : AnyObject] = [ErrorFileKey: file, ErrorLineKey: line]

  return failure(defaultError(userInfo))

}

public func failure<T>(error: ErrorType) -> Result<T> {

  return .Failure(error)

}

So failure(error) still works just like always. But now failure() will create an error that includes its source line number and file, and failure("string") will create an error that includes its source line number, file, and a message. That's all very convenient, but I worry that different people may want different things in their userInfo. Most notably, they may not want the full build path to the file dumped into the error object. Obviously people can work around it, but I worry about having creating something in Core that people would ever need to work around. (And of course sticking a potentially unlocalized string into NSLocaledDescriptionKey may also be bad form, though it's really on the caller to wrap it in NSLocalizedString() if they want that.)

That said, having failure() do *something* by default is insanely convenient during early development. Maybe you can argue it's *too* convenient, and we should force people to at least put something in there, but I think people can search for "failure()" just as easily as they can search for any other "put a real error here" placeholder.

Thoughts? Is this valuable enough to be in Core? Should any of it be moved up a level as a helper function? I don't want to put any extensions on NSError. That's something apps should do, but I think it's dangerous for LlamaKit.

-Rob