Some comments on trait-impl-macros

[scottmcm]

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.

[blueglyph]

Just a quick question: Didn't the utterance work for you? I was surprised to see your comments in a separate issue, here.

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

Could you please elaborate? I don't see what you mean. I never claimed that I was acting on anyone's behalf.

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

That's one way to do it, but you have to admit that it's not ideal. I'm not sure what you mean by now either. There's no 'official' method but a choice of several forms, which is the point I'm trying to make. In comparison, what has been done for strings and arrays is better, and we would benefit from an 'official' hashmap macro, which would make everything more coherent.

Every exception is a potential source of error and a difficulty to memorize the idioms. We see this problem in the exclusive ranges too, for example.

All the crates that are providing macros for the hashmap demonstrate this, so I think it's a valid suggestion to incorporate one of them.

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

I was talking about the forward_ref macros (cfr. beginning of the paragraph), not the trait implementations, which are already public.

No, because stability promises are expensive.

My sentence was an allusion to the difficulty to see where these implementations are, and how they are made ('declarative macros doing the same implementation'). I explained that in length before, and I summarize that in the conclusion with another perspective, that's all.

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

Again, I've never said every macro should be make public. The idea is that the declarative macros are not very clear and do a repetitive job. One part of the job could be simplified (the proposal in this article) and the implementation for the references could be shared (the helpful forward_ref macro mentioned earlier).

I hope this clarifies. :)

[scottmcm]

Could you please elaborate? I don't see what you mean. I never claimed that I was acting on anyone's behalf.

If I go to sign in with github to comment on the blog, it asks for "Act on your behalf" permissions. There's no way I'm giving your website permissions to take arbitrary actions as me on GitHub.

I was talking about the forward_ref macros (cfr. beginning of the paragraph), not the trait implementations, which are already public.

But the argument is "if they're good enough for all the implementations in an essential library", and that's not sufficient to conclude "they must be worth sharing", as my example of another macro that meets the predicate shows.

[blueglyph]

If I go to sign in with github to comment on the blog, it asks for "Act on your behalf" permissions. There's no way I'm giving your website permissions to take arbitrary actions as me on GitHub.

Ah, I see, thanks for the feedback. I hesitated between several options but couldn't find anything entirely satisfying. If you have any suggestion, feel free to share them.

Utterances is well-known and open-source, so I didn't expect it would be a problem, but commenting like you did is fine.

But the argument is "if they're good enough for all the implementations in an essential library", and that's not sufficient to conclude "they must be worth sharing", as my example of another macro that meets the predicate shows.

Your example doesn't show the macros I'm talking about, which are in the internal_macros.rs file. Those are used everywhere and worth sharing.

Instead, you're showing me an entire trait implementation, which is already publicly shared and which isn't used elsewhere in that library, so something entirely different. It actually reinforces my argument: they're not easy to read, and the IDE cannot provide any assistance.

In comparison, the forward_ref macros are used many times in the Standard Library as a very efficient tool to implement the traits for references. For example, as I've shown above:

forward_ref_binop! { impl const Shl, shl for $t, $f }

The proof they're well worth sharing is that 2 crates are doing that now, except they don't have all the features of what is in internal_macros.rs (understandably). It's not a critic of those crates, but it shows that we could have the same result or even better with less effort.

[blueglyph]

By the way, you're not giving my website permission to act on your behalf on GitHub. You're giving utterances the right to comment on your behalf, see here:

https://utteranc.es/