`#[stub]` attribute and lint warning, similar to `#[deprecated]`

[abonander]

Working on my Reddit API Wrapper for Rust (RAWR), I would like to let people play around with it before the wrapper is complete, since it’s almost basically functional but far from stable. I’ve stubbed out a lot of the API by declaring functions that only contain unimplemented!(). This way, people can see and critique the design of the API so I can adjust it before I put in the work to implement it, and I can work on one part at a time while building against APIs that don’t actually exist yet.

I’d like to have a #[stub] attribute that triggers a lint warning–like #[deprecated], except with the opposite motivation: instead of warning users about features that work now but won’t in the future, it would be warning users about features that don’t work now, but will in the future, so they can know about this at compile time instead of having to find out at runtime with a failure triggered by unimplemented!(). It would also appear in the docs like the other status flags such as #[stable] and #[experimental].

I think this would be a useful feature for any API developer because it allows them to safely tinker with stubbed-out APIs in their master branch without surprising or confusing early adopters.

[dobkeratops]

nice idea, I’ve got a related use case which is to have a trait with ‘too many’ functions most of which default to “fail!()”, different types may implement a different subset of these functions; The idea would be to use simpler, bigger traits before cutting them up & implementing combined traits… to cut down on micromanagement whilst experimenting.

Something that prevents it compiling would handle this much better - it should be a compile-time failure to call such an unimplemented, whereas at present with this approach the program would compile, but give a runtime failure.