I just started with Rust and came across this problem. Is there a way to enforce the supertrait on the derived implementation? Or is there any kind of trait grouping?
In this specific case I want to implement a trait which bundles all the basic operator overloadings aka. + - * / += ... and use this trait on different implementations.
Example not acutally valid code:
//grouping of traits
trait Number: std::ops::Add + std::ops::Sub .... { }
#[derive(Debug)]
struct Complex {
re: f64,
im: f64
}
impl Number for Complex {
// ---snip----
}
//usage
fn main() {
let a = Complex { re: 1.0, im: 2.0 };
let b = Complex { re: 3.0, im: 4.0 };
println!("Result of a + b = {:?}", a + b);
}
As I currently understand the supertrait topic I am only able to use those overloaded operators INSIDE the trait definition of the subtrait, is this correct?
Is there any other way to "group" traits like the operator overloading traits to use as a single traitlike entity?
Thanks
Generally when creating a supertrait, you define the trait with the given subtraits:
// Grouping of traits
trait Number
where
Self: std::ops::Add<Output = Self> + std::ops::Sub<Output = Self> + Sized
{}
And then you implement that trait for any type that also implements the given subtraits:
impl<T> Number for T
where
Self: std::ops::Add<Output = Self> + std::ops::Sub<Output = Self> + Sized
{}
Then you can use it like so:
fn add<T: Number>(a: T, b: T) -> T {
a + b
}
fn sub<T: Number>(a: T, b: T) -> T {
a - b
}
But you'll still need to implement all of the subtraits for any type that you want to use the supertrait with.
playground
Related
I have a generic function that prints the minimum of two items:
use std::fmt::Display;
fn print_min<T: PartialOrd + Display>(a: &T, b: &T) {
println!("min = {}", if a < b { a } else { b });
}
This works pretty well with anything that implements both the PartialOrd and Display traits:
print_min(&45, &46);
// min = 45
print_min(&"a", &"b");
// min = a
Having to put the PartialOrd + Display in the function definition is kind of ugly, especially if I want to have a whole bunch of functions that operate on this (implementing a binary search tree, for example), or if my bounds get more complex. My first inclination was to attempt to write a type alias:
type PartialDisplay = PartialOrd + Display;
but this gives me some fairly bizarre compiler errors:
error[E0393]: the type parameter `Rhs` must be explicitly specified
--> src/main.rs:7:23
|
7 | type PartialDisplay = PartialOrd + Display;
| ^^^^^^^^^^ missing reference to `Rhs`
|
= note: because of the default `Self` reference, type parameters must be specified on object types
error[E0225]: only auto traits can be used as additional traits in a trait object
--> src/main.rs:7:36
|
7 | type PartialDisplay = PartialOrd + Display;
| ^^^^^^^ non-auto additional trait
I'm guessing either my syntax is wrong or this just isn't possible yet. I'd like something like
type PartialDisplay = ???
fn print_min<T: PartialDisplay> { /* ... */ }
PartialOrd and Display are traits. It has been discussed how to implement an alias but it was decided that it wasn't needed.
Instead, you can create a new trait with the traits you want as super traits and provide a blanket implementation:
use std::fmt::Display;
trait PartialDisplay: PartialOrd + Display {}
impl<T: PartialOrd + Display> PartialDisplay for T {}
fn print_min<T: PartialDisplay>(a: &T, b: &T) {
println!("min = {}", if a < b { a } else { b });
}
fn main() {
print_min(&45, &46);
print_min(&"aa", &"bb");
}
RFC 1733 introduced the concept of a trait alias. When it is stabilized, you will be able to say:
#![feature(trait_alias)]
use std::fmt::Display;
trait PartialDisplay<Rhs = Self> = PartialOrd<Rhs> + Display;
fn print_min<T: PartialDisplay>(a: &T, b: &T) {
println!("min = {}", if a < b { a } else { b });
}
fn main() {
print_min(&45, &46);
print_min(&"a", &"b");
}
While awaiting the stabilization of trait aliasing, you can use the trait-set crate. Here is an example of its use:
trait-set! {
pub trait HashKey = Hash + Eq + Clone
}
I have some problems generalizing a trait working for &str to other string types (e.g. Rc<str>, Box<str>,String).
First of all my example function should work for:
assert_eq!(count("ababbc", 'a'), 2); // already working
assert_eq!(count(Rc::from("ababbc"), 'a'), 2); // todo
assert_eq!(count("ababbc".to_string(), 'a'), 2); // todo
This is the working code, which makes the first test run:
pub trait Atom: Copy + Eq + Ord + Display + Debug {}
impl Atom for char {}
pub trait Atoms<A, I>
where
I: Iterator<Item = A>,
A: Atom,
{
fn atoms(&self) -> I;
}
impl<'a> Atoms<char, std::str::Chars<'a>> for &'a str {
fn atoms(&self) -> std::str::Chars<'a> {
self.chars()
}
}
pub fn count<I, A, T>(pattern: T, item: A) -> usize
where
A: Atom,
I: Iterator<Item = A>,
T: Atoms<A, I>,
{
pattern.atoms().filter(|i| *i == item).count()
}
To make the next tests run, I changed the signature of count and Atoms in following way:
pub trait Atoms<'a, A, I>
where
I: Iterator<Item = A> + 'a,
A: Atom,
{
fn atoms<'b>(&'b self) -> I
where
'b: 'a;
}
impl<'a, S> Atoms<'a, char, std::str::Chars<'a>> for S
where
S: AsRef<str> + 'a,
{
fn atoms<'b>(&'b self) -> std::str::Chars<'b>
where
'b: 'a,
{
self.as_ref().chars()
}
}
but now the function count does not compile any more:
pub fn count<'a, I, A, T>(pattern: T, item: A) -> usize
where
A: Atom,
I: Iterator<Item = A> + 'a,
T: Atoms<'a, A, I>,
{
pattern.atoms().filter(|i| *i == item).count()
}
Playground-Link
The compiler error is: the parameter type 'T' may not live long enough ... consider adding an explicit lifetime bound...: 'T: 'a'. This is not completely understandable for me, so I tried to apply the help T: Atoms<'a, A, I> + 'a. Now the error is: 'pattern' does not live long enough ... 'pattern' dropped here while still borrowed.
Since the latter error also occurs without implementations of Atoms and by just replacing the function body by pattern.atoms();return 1; I suspect that the type signature of Atoms is not suitable for my purpose.
Has anybody a hint what could be wrong with the type signature of Atoms or count?
trait Atoms<'a, A, I> where I: Iterator<Item = A> + 'a ...
By writing this, you're requiring the iterator to outlive the lifetime 'a. Since 'a is part of the trait's generic parameters, it must be a lifetime that extends before you start using (implicitly) <String as Atoms<'a, char, std::str::Chars>>::atoms. This directly contradicts the idea of returning a new iterator object, since that object did not exist before the call to atoms().
Unfortunately, I'm not sure how to rewrite this so that it will work, without generic associated types (a feature not yet stabilized), but I hope that at least this explanation of the problem helps.
I hope I clarify at least some parts of the problem. After doing some internet research on HRTBs and GATs I come to the conclusion that my problem is hardly solvable with stable rust.
The main problem is that one cannot
have a trait with different lifetime signature than its implementations
keep lifetimes generic in a trait for later instantiation in the implementation
limit the upper bound of a results lifetime if it is owned
I tried several approaches to but most evolve to fail:
at compiling the implementation (because the implementations lifetimes conflict with those of the trait)
at compiling the caller of the trait because a compiling implementation limits the lifetimes in a way, that no object can satisfy them.
At last I found two solutions:
Implement the trait for references
the function atoms(self) does now expect Self and not &Self
Atoms<A,I> is implemented for &'a str and &'a S where S:AsRef<str>
This gives us control of the lifetimes of the self objects ('a) and strips the lifetime completely from the trait.
The disadvantage of this approach is that we have to pass references to our count function even for smart references.
Playground-Link
use std::fmt::Display;
use std::fmt::Debug;
pub trait Atom: Copy + Eq + Ord + Display + Debug {}
impl Atom for char {}
pub trait Atoms<A, I>
where
I: Iterator<Item = A>,
A: Atom,
{
fn atoms(self) -> I;
}
impl<'a> Atoms<char, std::str::Chars<'a>> for &'a str {
fn atoms(self) -> std::str::Chars<'a> {
self.chars()
}
}
impl<'a, S> Atoms<char, std::str::Chars<'a>> for &'a S
where
S: AsRef<str>,
{
fn atoms(self) -> std::str::Chars<'a> {
self.as_ref().chars()
}
}
pub fn count<I, A, T>(pattern: T, item: A) -> usize
where
A: Atom,
I: Iterator<Item = A>,
T: Atoms<A, I>,
{
pattern.atoms().filter(|i| *i == item).count()
}
#[cfg(test)]
mod tests {
use std::rc::Rc;
use super::*;
#[test]
fn test_example() {
assert_eq!(count("ababbc", 'a'), 2);
assert_eq!(count(&"ababbc".to_string(), 'a'), 2);
assert_eq!(count(&Rc::from("ababbc"), 'a'), 2);
}
}
Switch to Generic Associated Types (unstable)
reduce the generic type Atoms<A,I> to an type Atoms<A> with an generic associated type I<'a> (which is instantiable at implementations)
now the function count can refer to the lifetime of I like this fn atoms<'a>(&'a self) -> Self::I<'a>
and all implementations just have to define how the want to map the lifetime 'a to their own lifetime (for example to Chars<'a>)
In this case we have all lifetime constraints in the trait, the implementation can consider to map this lifetime or ignore it. The trait, the implementation and the call site are concise and do not require references or helper lifetimes.
The disadvantage of this solution is that it is unstable, I do not know whether this means that runtime failures would probably occur or that api could change (or both). You will have to activate #![feature(generic_associated_types)] to let it run.
Playground-Link
use std::{fmt::Display, str::Chars};
use std::{fmt::Debug, rc::Rc};
pub trait Atom: Copy + Eq + Ord + Display + Debug {}
impl Atom for char {}
pub trait Atoms<A>
where
A: Atom,
{
type I<'a>: Iterator<Item = A>;
fn atoms<'a>(&'a self) -> Self::I<'a>;
}
impl Atoms<char> for str
{
type I<'a> = Chars<'a>;
fn atoms<'a>(&'a self) -> Chars<'a> {
self.chars()
}
}
impl <S> Atoms<char> for S
where
S: AsRef<str>,
{
type I<'a> = Chars<'a>;
fn atoms<'a>(&'a self) -> Chars<'a> {
self.as_ref().chars()
}
}
pub fn count<A, S>(pattern: S, item: A) -> usize
where
A: Atom,
S: Atoms<A>,
{
pattern.atoms().filter(|i| *i == item).count()
}
#[cfg(test)]
mod tests {
use std::rc::Rc;
use super::*;
#[test]
fn test_example() {
assert_eq!(count("ababbc", 'a'), 2);
assert_eq!(count("ababbc".to_string(), 'a'), 2);
assert_eq!(count(Rc::from("ababbc"), 'a'), 2);
}
}
I am trying to extend the functionality of the Iterator trait.
My statistics/iter_statistics.rs:
mod iter_statistics {
pub trait IterStatistics: Iterator<Item = f64> {
fn foo(&mut self) -> f64 {
0.0
}
}
impl IterStatistics for Iterator<Item = f64> {}
}
And statistics/mod.rs:
pub use self::iter_statistics::*;
mod iter_statistics;
And finally in my test code I have
use statistics::IterStatistics;
fn main() {
let z: Vec<f64> = vec![0.0, 3.0, -2.0];
assert_eq!(z.into_iter().foo(), 0.0);
}
When I run the test, I get:
error: no method name `foo` found for type `std::vec::IntoIter<f64>` in the current scope
assert_eq!(z.into_iter().foo(), 0.0);
^~~
which is strange to me since the docs for IntoIter<T> say it implements Iterator<Item=T>.
The impl you have written will only apply to trait objects (e.g. &mut Iterator<Item=f64>), not for all types that implement Iterator<Item=f64>. You want to write a generic impl like this:
impl<T: Iterator<Item=f64>> IterStatistics for T {}
Your implementation is backward. When programming in Rust, you have to forget about OO-inheritance and reason in terms of capabilities.
What does trait D: B means in Rust?
This means that D can only be implemented for types that already implement B. It's not inheritance, it's a constraint.
When to use trait D: B then?
The main reason to use this constraint is when you wish to provide a default implementation of D methods that will require associated items (traits, constants, methods) from B.
In general, you do not want to add more constraints than strictly necessary, as your clients may wish to use this trait in ways you did not foresee.
The one exception is when creating a trait as a "bundle of constraints", so that you do not have type T: SomeTrait + SomeOtherTrait + Send for all the methods your are implementing. This "bundle of constraints" should be empty, then; it's not a functional trait after all, just an "alias".
So, how to extend Iterator?
First declare a new trait:
pub trait IterStatistics {
fn foo(&mut self) -> f64;
}
Then implement it for all types already implementing Iterator<Item = f64>:
impl<T> IterStatistics for T
where T: Iterator<Item = f64>
{
fn foo(&mut self) -> f64 {
0.0
}
}
I'm trying to redefine the Add trait so that I could use it as infix operator:
//use std::ops::Add;
trait Add<RHS=Self> {
// type Output;
fn add(self, rhs: RHS) -> Self;
}
fn summ<T: Add>(a: T, b: T) -> T {
a+b
} // doesn't compile
Is it possible to redefine the Add trait so that it will use the + operator for add functionality?
It is not possible to redefine any traits. You could create your own trait with the same name and same methods, which is what you have done. However, the operator + is tied to std::ops::Add, so it wouldn't be useful in this case.
In your case, it looks like you just want to specify Add::Output to return a T:
use std::ops::Add;
fn summ<T>(a: T, b: T) -> T
where T: Add<Output = T>
{
a + b
}
I have a generic function that prints the minimum of two items:
use std::fmt::Display;
fn print_min<T: PartialOrd + Display>(a: &T, b: &T) {
println!("min = {}", if a < b { a } else { b });
}
This works pretty well with anything that implements both the PartialOrd and Display traits:
print_min(&45, &46);
// min = 45
print_min(&"a", &"b");
// min = a
Having to put the PartialOrd + Display in the function definition is kind of ugly, especially if I want to have a whole bunch of functions that operate on this (implementing a binary search tree, for example), or if my bounds get more complex. My first inclination was to attempt to write a type alias:
type PartialDisplay = PartialOrd + Display;
but this gives me some fairly bizarre compiler errors:
error[E0393]: the type parameter `Rhs` must be explicitly specified
--> src/main.rs:7:23
|
7 | type PartialDisplay = PartialOrd + Display;
| ^^^^^^^^^^ missing reference to `Rhs`
|
= note: because of the default `Self` reference, type parameters must be specified on object types
error[E0225]: only auto traits can be used as additional traits in a trait object
--> src/main.rs:7:36
|
7 | type PartialDisplay = PartialOrd + Display;
| ^^^^^^^ non-auto additional trait
I'm guessing either my syntax is wrong or this just isn't possible yet. I'd like something like
type PartialDisplay = ???
fn print_min<T: PartialDisplay> { /* ... */ }
PartialOrd and Display are traits. It has been discussed how to implement an alias but it was decided that it wasn't needed.
Instead, you can create a new trait with the traits you want as super traits and provide a blanket implementation:
use std::fmt::Display;
trait PartialDisplay: PartialOrd + Display {}
impl<T: PartialOrd + Display> PartialDisplay for T {}
fn print_min<T: PartialDisplay>(a: &T, b: &T) {
println!("min = {}", if a < b { a } else { b });
}
fn main() {
print_min(&45, &46);
print_min(&"aa", &"bb");
}
RFC 1733 introduced the concept of a trait alias. When it is stabilized, you will be able to say:
#![feature(trait_alias)]
use std::fmt::Display;
trait PartialDisplay<Rhs = Self> = PartialOrd<Rhs> + Display;
fn print_min<T: PartialDisplay>(a: &T, b: &T) {
println!("min = {}", if a < b { a } else { b });
}
fn main() {
print_min(&45, &46);
print_min(&"a", &"b");
}
While awaiting the stabilization of trait aliasing, you can use the trait-set crate. Here is an example of its use:
trait-set! {
pub trait HashKey = Hash + Eq + Clone
}