Determine if a type implements a logical trait expression?, brought to you by @NikolaiVazquez!
This library defines impls!
, a macro? that returns
a bool
indicating whether a type implements a boolean-like expression over a
set of traits?.
assert!(impls!(String: Clone & !Copy & Send & Sync));
See "Examples" for detailed use cases and, if you're brave, see "Trait-Dependent Type Sizes" for some cursed code.
As a library author, it's important to ensure that your API remains stable.
Trait implementations are part of API stability. For example: if you
accidentally introduce an inner type that makes your publicly-exposed type no
longer be Send
or Sync
, you've now broken your API without noticing it!
The most common case of this happening is adding a raw pointer
(i.e. *const T
, *mut T
) as a type field.
By checking situations like this with impls!
, either at compile-time or in
a unit test, you can ensure that no API-breaking changes are made without
noticing until it's too late.
This crate is available on crates.io and can be used by adding the
following to your project's Cargo.toml
:
[dependencies]
impls = "1"
and this to your crate root (main.rs
or lib.rs
):
#[macro_use]
extern crate impls;
When using Rust 2018 edition, the following import can help if
having #[macro_use]
is undesirable.
use impls::impls;
This documentation uses jargon that may be new to inexperienced Rust users. This section exists to make these terms easier to understand. Feel free to skip this section if these are already familiar to you.
In Rust, macros are functions over the abstract syntax tree (AST). They map input tokens to output tokens by performing some operation over them through a set of rules. Because of this, only their outputs are ever type-checked.
If you wish to learn about implementing macros, I recommend:
- The Little Book of Rust Macros
- "Macros" - The Rust Programming Language
- "Macros" - The Rust Reference
- "Macros By Example" - The Rust Reference
To use this crate, you do not need to know how macros are defined.
In Rust, traits are a way of defining a generalized property. They should be
thought of expressing what a type is capable of doing. For example: if a
type implements Into
for some type T
, then we know it can be converted
into T
by just calling the .into()
method on it.
If you wish to learn about traits in detail, I recommend:
In this crate, traits should be thought of as bool
s where the condition
is whether the given type implements the trait or not.
An expression can be formed from these trait operations:
-
And (
&
): also known as logical conjunction, this returnstrue
if both operands aretrue
. This is usually defined in Rust via theBitAnd
trait. -
Or (
|
): also known as logical disjunction, this returnstrue
if either of two operands istrue
. This is usually defined in Rust via theBitOr
trait. -
Exclusive-or (
^
): also known as exclusive disjunction, this returnstrue
if only one of two operands istrue
. This is usually defined in Rust via theBitXor
trait. -
Not (
!
): a negation that returnsfalse
if the operand istrue
, ortrue
if the operand isfalse
. This is usually defined in Rust via theNot
trait.
See "Precedence and Nesting" for information about the order in which these operations are performed.
This macro works in every type context. See below for use cases.
Because types are compile-time constructs, the result of this macro can be
used as a const
value:
const IMPLS: bool = impls!(u8: From<u32>);
Using static_assertions
, we can fail to compile if the trait expression
evaluates to false
:
const_assert!(impls!(*const u8: Send | Sync));
Trait operations abide by Rust's expression precedence. To define a custom order of operations (e.g. left-to-right), simply nest the expressions with parentheses.
let pre = impls!(u64: From<u8> | From<u16> ^ From<u32> & From<u64>);
let ltr = impls!(u64: ((From<u8> | From<u16>) ^ From<u32>) & From<u64>);
assert_eq!(pre, true | true ^ true & true);
assert_ne!(pre, ltr);
Because exclusive-or (^
) is a trait operation, we can check that a type
implements one of two traits, but not both:
struct T;
trait Foo {}
trait Bar {}
impl Foo for T {}
assert!(impls!(T: Foo ^ Bar));
Something that's surprising to many Rust users is that &mut T
does not
implement Copy
nor Clone
:
assert!(impls!(&mut u32: !Copy & !Clone));
Surely you're thinking now that this macro must be broken, because you've
been able to reuse &mut T
throughout your lifetime with Rust. This works
because, in certain contexts, the compiler silently adds "re-borrows"
(&mut *ref
) with a shorter lifetime and shadows the original. In reality,
&mut T
is a move-only type.
There's a variety of types in Rust that don't implement Sized
:
// Slices store their size with their pointer.
assert!(impls!(str: !Sized));
assert!(impls!([u8]: !Sized));
// Trait objects store their size in a vtable.
trait Foo {}
assert!(impls!(dyn Foo: !Sized));
// Wrappers around unsized types are also unsized themselves.
struct Bar([u8]);
assert!(impls!(Bar: !Sized));
When called from a generic function, the returned value is based on the constraints of the generic type:
use std::cell::Cell;
struct Value<T> {
// ...
}
impl<T: Send> Value<T> {
fn do_stuff() {
assert!(impls!(Cell<T>: Send));
// ...
}
}
Keep in mind that this can result in false negatives:
const fn is_copy<T>() -> bool {
impls!(T: Copy)
}
assert_ne!(is_copy::<u32>(), impls!(u32: Copy));
Traits with lifetimes are also supported:
trait Ref<'a> {}
impl<'a, T: ?Sized> Ref<'a> for &'a T {}
impl<'a, T: ?Sized> Ref<'a> for &'a mut T {}
assert!(impls!(&'static str: Ref<'static>));
assert!(impls!(&'static mut [u8]: Ref<'static>));
assert!(impls!(String: !Ref<'static>));
This macro enables something really cool (read cursed) that couldn't be done before: making a type's size dependent on what traits it implements! Note that this probably is a bad idea and shouldn't be used in production.
Here Foo
becomes 32 bytes for no other reason than it implementing Clone
:
const SIZE: usize = 32 * (impls!(Foo: Clone) as usize);
#[derive(Clone)]
struct Foo([u8; SIZE]);
assert_eq!(std::mem::size_of::<Foo>(), 32);
The bool
returned from impls!
gets casted to a usize
, becoming 1 or
0 depending on if it's true
or false
respectively. If true
, this becomes
32 × 1, which is 32. This then becomes the length of the byte array in Foo
.
This abuses inherent impl
priority to determine that a trait is implemented:
// Fallback trait for to all types to default to `false`.
trait NotCopy {
const IS_COPY: bool = false;
}
impl<T> NotCopy for T {}
// Concrete wrapper type where `IS_COPY` becomes `true` if `T: Copy`.
struct IsCopy<T>(std::marker::PhantomData<T>);
impl<T: Copy> IsCopy<T> {
// Because this is implemented directly on `IsCopy`, it has priority over
// the `NotCopy` trait impl.
//
// Note: this is a *totally different* associated constant from that in
// `NotCopy`. This does not specialize the `NotCopy` trait impl on `IsCopy`.
const IS_COPY: bool = true;
}
assert!(IsCopy::<u32>::IS_COPY);
assert!(!IsCopy::<Vec<u32>>::IS_COPY);
-
Nikolai Vazquez (GitHub: @nvzqz, Twitter: @NikolaiVazquez)
Implemented the
impls!
macro with support for all logical operators and without the limitations of the initialdoes_impl!
macro by Nadrieril. -
Nadrieril Feneanar (GitHub: @Nadrieril)
Implemented the initial
does_impl!
macro in nvzqz/static-assertions-rs#28 upon which this crate was originally based.
This project is released under either:
at your choosing.