Subscribe to this issue to receive notifications on new posts.

Red's Blog

http://192.168.1.56:1111/posts/blog/

Red's Blog

https://www.unscript.net/redblog/posts/trait-impl-macros/

First, I'm not approving "Act on your behalf" to comment. That's way too broad.

let's consider the crates providing macros to instantiate a HashMap object

It's now [(a, b), (c, d)].into(), without needing a macro.

Finding the Right Crate

If you haven't already, be sure to try out https://lib.rs/ -- it's a more opinionated site that uses more heuristics and such to attempt to be more useful for some things than the normal crates dot io site.

Delegated curation is best, IMHO. Write a book about your topic (like https://rust-cli.github.io/book/index.html) and recommend crates for that domain in it.

I never want to spend reviewer bandwidth on fights over which not-owned-by-rust-lang crates should be mentioned in the standard library docs, for example, so the only reasonable option is to not link to any of them.

After all, if they're good enough for all the implementations in an essential library, they must be worth sharing.

This is definitely not true. For example, the 2468-line uint_impl is certainly not worth sharing

https://github.com/rust-lang/rust/blob/e013d8f8b3984ed2409e489f5d5183a0e3d091cf/library/core/src/num/uint_macros.rs#L1-L25

As as you pointed out, if it was made public, that would basically prevent changes like rust-lang/rust#108279 to make it easier to read in the callsites.

as if by resentment, showing no goodwill to share the code with us.

No, because stability promises are expensive.

"When we must repeat something several times, we consider automatizing it and sharing the code" is just as true for library developers -- that's why things like rust-lang/rust#102300 exist.

But it wouldn't happen if every internal macro had to have enough libs-api oversight to put it on the path to stabilization.

Macros are no different here from all the pub(crate) functions in the standard library that you can't use either, like https://stdrs.dev/nightly/x86_64-unknown-linux-gnu/alloc/vec/struct.IntoIter.html#method.into_vecdeque

On the overall idea

A bunch of this got caught up in the specialization problems.

There's long been a wish that there'd just be some sort of

#[bikeshed_fallback_impl]
impl<T: Copy> Add<&T> for &T
    where T: Add<T>
{
    type Output = <T as Add<T>>::Output;
    fn add(self, other: &T) -> Self::Output {
        *self + *other
    }
}

or similar in core so you never have to use a macro to implement those.

But specialization is a quagmire if the impls can depend on lifetimes, so it hasn't moved in ages.