Let's bikeshed on names! about failure

[withoutboats]

The crate name is failure. The derive crate will probably be renamed failure_derive since this is the most common naming scheme for derive crates.

[withoutboats]

This is the only issue opened so far that would be a breaking change to follow up on after the 0.1 release, so its the one we need to hash out ASAP. If you have alternative names, speak now or forever hold your peace. :-)

[DorianListens]

I’m a fan of both Fail and Error, for what it’s worth. I think the naming guidelines are worth following for consistency if nothing else, and the confusion over Error is probably worth it to simplify the common case.

[m4b]

This is somewhat related but do you plan to use - or underscore in crate name (for derive) ?

Also I thought derive_fail was unusual (as opposed to fail_derive)

Also the crate will be named failure or fail?

[troiganto]

Just throwing this out, but since the main purpose of the trait in question seems to be to universally 'cast' any error to the failure::Error type, would IntoError be a fitting name? The name seems to have some precedent in the standard library (IntoIterator comes to mind).

[troiganto]

That's a fair point. FWIW, I switched the application I'm working on from quick-error to failure yesterday. The refactor was straight-forward, removed a ton of boilerplate, and and all compiler warnings/errors afterwards were about missing or unused uses. So I'm very excited for the next release!

[withoutboats]

According to Rust's style guides, best practice is to name traits verbs (e.g. Read, Write, Display) and types nouns (e.g. Result, String, HashMap). Fail is an English verb and not intended to be a reference to a meme.

The Error struct is called Error so that the easiest thing to do is write Result<_, Error>. The transition from the current trait is unfortunate.

[withoutboats]

We did consider Error/AnyError as an alternative prior to publicizing this, but I'm pretty confident that would not be preferable.

[HadrienG2]

I did not know about this trait naming guideline, but it seems like in addition to being somewhat arbitrary, it does not reflect practical usage at all.

Just consider the standard library traits: you have Any, AsRef/AsMut, (Partial)Eq, Error, Fn, From/Into, Hasher, Iterator (Partial)Ord, Sized... It does seem like we did very well without the constraint that everything be a verb so far.

The convention of naming interfaces after nouns, on the other hand, has been established in the OO community for a long while, so deprecating it seems somewhat strange.

[withoutboats]

Its true that it hasn't been followed consistently (though "Ord[er]", "Eq[ual]" and "Error" are technically verbs). I don't even like it that much, but since it is the recommendation I'm inclined to follow it.

(more examples of it being followed: Clone, Hash, Debug, Default, almost all of the ops traits)

[HadrienG2]

Well, let's see if I'm the only one bothered by this naming convention or if others have better proposals, then. I will gladly admit to being terrible at naming things myself, it's just that for reasons described above, I have the impression that there has to be a better name for these two concepts somewhere, waiting to be found.

[withoutboats]

I'm open to renaming Fail if there is a better name out there, but I'm pretty committed to Error so that the obvious thing of making the Err variant of Result an Error will Just Work.

[U007D]

@HadrienG2 I agree that the trait vs. struct name collision is (and will continue to be) a source of confusion (I've run into this myself in the not-too-distant past). I also agree that some of the guideline choices seem questionable.

With that, my 2¢ is in agreement with @withoutboats that the best way forward (ie. best way to not introduce yet more confusion over and above what we already have) is to adhere to the guidelines, such as they are.

[repax]

IIRC, the motivation for that guideline was to have short trait names, e.g. Copy instead of Copyable. Personally, I think adjectives are a better fit for traits names. Verbs makes sense for (some) functions.

[m4b]

Yes please the second, had to lookup again that it was derive_fail instead of failure. It also matches serde, etc, and this way can easily see all the deriving crates at a glance

[withoutboats]

Planning to release this tomorrow afternoon (PST, aka about 10 to 12 hours from now). Since I don't plan to make breaking changes at least for the rest of the year I'm going to close this.

Changed the name of the derive crate to failure_derive but otherwise feel pretty happy with the original names. Thanks for the discussion though.

@troiganto Sorry I forgot to reply to your comment. Fail is useful separate from Error; though returning Error is often a good idea, there are use cases in which you don't want to do that. So I don't want to suggest that the only reason to implement the trait is to cast your type into Error.