On Saturday, 19 October 2013, Florian Weimer wrote: > > The problem is that if err is of type "error", "err != nil" is true > after the assignment of a pointer value to err. So the usual error > checking idiom doesn't work if your function returns a > pointer-to-struct (that implements the "error" interface) instead of a > (relatively opaque) "error" interface value.
Don't do that. Return an error, not a naked error implementation. If people want to inspect it rather than treat it as a string, they'll do a type assertion rather than just a nil check. Rust doesn't have type assertions, however I feel this could be handled satisfactorily by using concrete error types in Rust. Also, the whole nil vs nil thing is irrelevant to Rust. > Or put differently, if you put a typed null pointer into an interface > value, the interface value keeps the type information and is therefore > no longer equal to nil. Don't do that. Return either a nil error or a valid value of your error type. Seriously, the nil interface vs nil contents thing is only a tripping point for novices who don't understand what interfaces are, it's not something you run into once you've familiarized yourself with the language. This wouldn't be an issue in Rust, since people would really have to go out of their way to conflate an Err(None) with an Ok(v). That's not a chaining mechanism. > You're going to need to explain what you mean by this, then, and how it would apply to Rust. Note that if it's something very particular to how Go code is written, it's probably not constructive here.
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
