# Suggestion (Pre-RFC?): Implement Default for Result

**URL:** <https://internals.rust-lang.org/t/suggestion-pre-rfc-implement-default-for-result/14843>\
**Category:** libs\
**Created:** [June 6, 2021, 12:12pm UTC](https://internals.rust-lang.org/t/suggestion-pre-rfc-implement-default-for-result/14843 "2021-06-06T12:12:13Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![theodore23](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/theodore23/32/8010_2.png) [@theodore23](https://internals.rust-lang.org/u/theodore23)\
**Post date:** [June 6, 2021, 12:12pm UTC](https://internals.rust-lang.org/t/suggestion-pre-rfc-implement-default-for-result/14843/1 "2021-06-06T12:12:14Z")

</div>

I'd like to propose for the `Result<T, E>` struct, one of the most used container types in Rust to implement the `Default` trait in either this form:

```rust
impl<E> Default for Result<(), E> {
  fn default() -> Self { Ok(()) }
}

```

I'm sure that for most, if not all, use cases of `Result<(), Something>`, the unit value does represent the default, non-erroneous case and is in line with the semantics of the type.

### Alternatives

The trait could also be implemented generic over T:

```rust
impl<T: Default, E> Default for Result<T, E> {
  fn default() -> Self { Ok(<T as Default>::default()) }
}

```

However, the semantics of this are in my opinion much more debatable than the first case.

### Breakage

Because both the `Default` and `Result` are defined in the `std` crate, users can't implement this themselves, therefore I don't think this change could break any compilation.

* * *

Do you think this is a good idea? If yes, how should I proceed with this? Is it enough for making a formal RFC or is a pull request enough?

---

<div class="post-metadata">

**Author:** ![steffahn](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/steffahn/32/13288_2.png) [@steffahn](https://internals.rust-lang.org/u/steffahn)\
**Post date:** [June 6, 2021, 1:41pm UTC](https://internals.rust-lang.org/t/suggestion-pre-rfc-implement-default-for-result/14843/2 "2021-06-06T13:41:58Z")

</div>

A potential problem/confusion point is that `Option`ʼs default is `None`, so people _might_ expect an “error” value as the `Default` for `Result` as well.

Also Iʼd be curious about in what settings having the default implementation for `Result<(), E>` in particular is actually useful and in which way. AFAIK, default implementations are particularly useful for saving lots of typing long expressions if the type implementing `Default` is a larger struct with lots of fields; for helping with deriving default if the type is often used as a field or generic parameter in the type of a field of a struct; for allowing `mem::take`; and for marking some conceptually clear default variant of e. g. a configuration enum or struct or similar things, for structs also for using the builder pattern.

I don't use Rust in practice myself though, so I'm probably missing use cases. Anyway, of the cases above that I could think of, not much applies to `Result`. Unless `Result<(), E>` often appears in the type of your struct fields, I'm really not sure of the use case, but you'll probably have one, otherwise you wouldn't suggest the implementation in the first case, right?

---

<div class="post-metadata">

**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\
**Post date:** [September 4, 2021, 4:43pm UTC](https://internals.rust-lang.org/t/suggestion-pre-rfc-implement-default-for-result/14843/4 "2021-09-04T16:43:10Z")

</div>

Closed on September 4, 2021, 4:43pm UTC

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.