Rename AllocErr to AllocError

[SimonSapin]

Almost every error type in the standard library is named SomethingError, not SomethingErr. The one exception is LayoutErr, which is stable and so can’t easily be renamed. Although LayoutErr has more "proximity" to AllocErr (being in the same module) I think we should leave it as a lone inconsistency rather than make it a second naming pattern to follow.

[TimDiekmann]

I think we should leave it as a lone inconsistency rather than make it a second naming pattern to follow.

As we are in the module alloc we should then rename it to Error to follow the naming pattern in std (io::Error and fmt::Error, not IoError and FmtError). Search results for Error

[SimonSapin]

Maybe, though those modules only have one error type while std::alloc also has LayoutErr. I could still live with this.

[SimonSapin]

On a less serious note, we also have an alloc::alloc::alloc function ;)

[TimDiekmann]

Maybe, though those modules only have one error type while std::alloc also has LayoutErr. I could still live with this.

AllocError is the main error type in alloc. Personally I think Layout(Err) should live in mem instead of alloc, right next to align_of and size_of.

[SimonSapin]

That… hadn’t occurred to me but it makes sense. It may even be worth making the move and having re-exports for compat.

[TimDiekmann]

Actually I was just about posting a proposal... #59

[TimDiekmann]

We should decide, if we want AllocErr to be renamed to Error or AllocError. Other modules like core::fmt also have the Error type and it's known pattern to rust users, that different Errors occurs in core/std. Anyway, we also have core::alloc::LayoutErr (stable) and this will not be moved until we use Layout outside of std::alloc (see #59 and rust-lang/rust#71856). However, AllocErr is the "main-error" type in core::alloc, which is an argument for renaming it to Error.

One other thing to consider is, that AllocError may occure alongside other errors more often as soon as a user decides to use a fallible allocation API.

We basically have to decide, if we want to go the old std-way or the explicit way here.

[Amanieu]

I don't mind the way it is right now, especially considering LayoutErr and AllocErr are likely to be used together a lot.

[exrook]

Doing a quick survey of all the error types in std, we have:

Error

std::io::Error
std::fmt::Error

_ Error

std::array::TryFromSliceError
std::cell::BorrowError
std::cell::BorrowMutError
std::char::CharTryFromError
std::char::DecodeUtf16Error
std::char::ParseCharError
std::collections::TryReserveError [unstable]
std::env::JoinPathsError
std::env::VarError
std::ffi::FromBytesWithNulError
std::ffi::FromVecWithNulError [unstable]
std::ffi::IntoStringError
std::ffi::NulError
std::io::IntoInnerError
std::net::AddrParseError
std::num::ParseFloatError
std::num::ParseIntError
std::num::TryFromIntError
std::option::NoneError
std::path::StripPrefixError
std::str::Utf8Error
std::string::FromUtf16Error
std::string::FromUtf8Error
std::string::ParseError
std::sync::PoisonError
std::sync::TryLockError 
std::sync::mpsc::RecvError
std::sync::mpsc::RecvTimeoutError 
std::sync::mpsc::SendError
std::sync::mpsc::TryRecvError
std::sync::mpsc::TrySendError
std::thread::AccessError
std::time::SystemTimeError

_ Err

std::alloc::LayoutErr

I think it makes the most sense to go with AllocError to be consistent with the majority of the other error types. Also, as Tim mentioned, AllocError will likely be used in code with other application specific error types so I don't think it makes sense to go down the std::alloc::Error path.

Also I think it would be nice if we could deprecate LayoutErr with LayoutError just for consistency.

[Lokathor]

pub type LayoutError = LayoutErr; would solve a lot

[TimDiekmann]

Is it possible to write

#[stable]
pub type LayoutError = LayoutErr;

and deprecate LayoutErr without getting a warning when using LayoutError?

Is a type alias 100% backwards compatible when changing it to the actual struct? Or vice versa?

[TimDiekmann]

Iff we change LayoutErr to LayoutError, do we still want it in core::alloc or should we move it to core::mem? Related: #59 and rust-lang/rust#71856