Macros that implement AsRef and AsMut break an existing code about bitvec HOT 2 CLOSED

This is a common problem when using traits that are generic in the trait, rather than in the method. Rust's type resolver does not handle ambiguity in intermediate positions of expressions, so if an expression such as item.trait_call() can denote multiple expansions to multiple types, it will not attempt to choose one.

The problem is that the .as_ref() calls can refer to both <[T; N] as AsRef<[T]>>::as_ref(&[T; N]) -> &[T] and <[T; N]> as AsRef<BitSlice<_, T>>::as_ref(&[T; N]) -> &BitSlice<_, T>.

When working with fixed-size arrays, the coercion from [T; N] to [T] can be accomplished through, as you note, .as_{ref,mut}() without any imports (As{Ref,Mut} are in the implicit prelude); .borrow_{,mut}() with an import (std::borrow::Borrow{,Mut} are not), or, as you note, through range indexing ([..]). Use of .as_{ref,mut}() is generally not preferred except when the result of the method call is going directly to a statically-typed slot, precisely because the call is ambiguous.

For what it's worth, you don't actually need to explicitly reborrow when indexing: the expressions (&{,mut} value[..]).method() and value[..].method() are equivalent. This also has the advantage of declaring that the value is being interpreted as a slice, rather than creating a view of another type, which is what the As{Ref,Mut} traits do.

All that said, I've been deliberating whether to remove the As{Ref,Mut}<BitSlice<_, T>> implementations as I wrote this. As this issue demonstrates, the .as_{ref,mut}() view production does not allow users to specify the type of the view produced in the method call: it must be done with a fixed-type binding site (let view: &View = expr.as_ref();) or explicit call (AsRef::<View>>::as_ref(&expr). This must be done for production of BitSlice views anyway, as they have an additional type parameter that cannot be taken from the source expression.

I think the correct thing to do is to remove the As{Ref,Mut} implementations, since I provide a trait to produce views that does correctly collect the missing type parameter.

Thanks for this issue; the next minor-version release will remove the traits.

from bitvec.

Thanks for the problem fix and such a detailed explanation!

from bitvec.