Pre-pre-RFC: syntactic sugar for `Default::default()`

language design
10

I’ve noticed the calls for "syntactic sugar" or need for macros in Rust just because of its wordiness / explicitness. Default::default() is one example. Another one is all those helper macros for implementing traits in crates like derive_more or smart_default. Coming from Haskell I mostly see artificial and unnecessary problems here.

In Haskell, functions from type classes (i.e. traits) are never namespaced under the name of the typeclass. So when importing the Default class, you can immediately just write def where a Rustacean needs to write Default::default(). Thats 3 vs 18 characters. The artificial problem here is that what is unavoidable in Haskell (non-namespaced functions from traits) is impossible in Rust, without resorting to writing a new wrapper function.

At least the wrapper function is possible so you can

fn def<T: Default>() -> T {Default::default()}

and your problem goes away

Foo {
  bar: [Bar {
    qux: [Qux {
      zap: [Zap {
         val: "val",
         ..def()
      }],
      ..def()
    }],
    ..def()
  }],
  ..def()
}

I would be quite happy, if the wraper function could be replaced by a

use Default::default as def;

Also having Default::default pre-imported (as default) in the prelude is kind-of a must.

I won’t go too much into my off-topic point about implementing traits but I see a big problem in this need of re-stating the entire function/method signature of every function/method in every trait impl. I don’t think these helper macro crates were half as popular if implementing traits was more fun and less boilerplate. (And, by the way, I don’t think that the explicit signatures are the only problem that makes implementing traits tedious. There’s lots of room for improvement, including things Haskell doesn’t have (yet) either.)

9 Likes