Unexpected productivity boost of Rust

I find a healthy dose of todo!() is excellent for this.

    match foo {
      (3...=5, x, BLABLABLA) => easy(x),
      _ => todo!("I should actually implement this for non-trivial cases"),
    }

The nice thing about todo!() is that it type checks, obviously it always diverges so the type match is trivial, but it means this compiles and, so long as we don't cause the non-trivial case to happen, it even works at runtime.

The thing is I want an equivalent to `todo!()` for the type-system. A mode of operation where if you have some compile errors, you can still run tests. Like for example, if you have

    fn foo() -> impl Display {
        NotDisplay::new()
    }

and a test references `foo`, then it gets replaced for the purposes of the test with

    fn foo() -> impl Display {
        panic!("`NotDisplay` doesn't `impl Display`")
    }

This should not be part of the language, but part of the toolchain.

Same thing for the borrow-checker.

So maybe a proc macro which lets you #[dummy(Clone,Eq,PartialEq)] instead of #[derive(Clone,Eq,PartialEq)] ?

Although you said "mode of operation" and I can't get behind that idea, I think the choice to just wrap overflow by default for the integer types in release builds was probably a mistake. It's good that I can turn it off, but it shouldn't have been the default.

can't you just put the panic in foo()? That returns !

Sounds like 'Typed Holes'[1] in the Haskell ecosystem.

[1]: https://downloads.haskell.org/~ghc/7.10.3-rc1/users_guide/ty...

What's the advantage of that over putting `return todo!();` at the top of `foo()`? You do have to go through and mark the places where you have further work to do, but you don't have to finish the refactor.

I'm proposing this not as a specific feature but as a general strategy: everything the compiler can conceivably recover from in a way that allows the rest of the application to run, should. Think borrow checking, for example. If it could be changed automatically to Arc<Mutex<T>> from &T, when running the test you could say not only the borrow checker error, but also point at the specific runtime case that the borrow checker protected you from if any test exercises it.

Adding `return todo!()` works well enough for some cases, but not all, because it can't confirm against impl Trait return types.

And these strategies are things that people need to be taught about, individually. I'm not saying that the current state is terrible, just that there might be things we can do to make them better.

> I'm proposing this not as a specific feature but as a general strategy: everything the compiler can conceivably recover from in a way that allows the rest of the application to run, should.

I do think that'd be useful in a variety of cases, especially for testsuites. I don't think I'd want to go as far as trying to guess how to substitute `Arc`/`Mutex`/`RwLock` for a failed borrow, but there are a few different strategies that do seem reasonably safe.

In addition to the automatic todo!() approach, there's the approach of compile-time tainting of branches of the item tree that failed to compile. If something doesn't compile, turn it into an item that when referenced makes the item referencing it also fail to compile. That would then allow any items that do compile to get tested in the testsuite.

> Adding `return todo!()` works well enough for some cases, but not all, because it can't confirm against impl Trait return types.

Not in the fully general case, but ! does implement Display, so it would work in the case you posted.