Display and Error traits are clunky

[andrewrk]

here's a diff I just made:

-impl std::error::Error for CreationError {
-    fn description(&self) -> &str {
+impl CreationError {
+    fn to_string(&self) -> &str {
         match self {
             &CreationError::OsError(ref text) => text.as_slice(),
             &CreationError::NotSupported => "Some of the requested attributes are not supported",
@@ -82,6 +82,18 @@ impl std::error::Error for CreationError {
     }
 }

+impl std::fmt::Display for CreationError {
+    fn fmt(&self, formatter: &mut std::fmt::Formatter) -> Result<(), std::fmt::Error> {
+        formatter.write_str(self.to_string())
+    }
+}
+
+impl std::error::Error for CreationError {
+    fn description(&self) -> &str {
+        self.to_string()
+    }
+}
+

Display::fmt cannot call Error::description because Error trait requires Display trait. So I end up creating yet another method, and the other two call it. Pretty clunky when I just wanted a single to_string-like method.

[huonw]

It should be possible for Display to call Error; a trait inheritance requirement A: B + C just means that B and C have to be implemented if A is implemented, it's not imposing any ordering constraints on the implementations.

[shepmaster]

I found I had to explicitly cast self to call Error methods from Display:

let as_err = self as &error::Error;

I agree that it's clunky - I also wish that Error had a way of including details, but I understand it's a hard requirement.

[alexcrichton]

As @huonw mentioned there's not actual ordering restriction, you can call description from fmt. I think in this case you just need to make sure that the Error trait is in scope.