> This would be a big step away from the advantages of Rust's current
> trait system. Right now, if the definition of a generic function type
> checks, it's valid for all possible types implementing the trait
> bounds. There are no hidden or implicit requirements.
Yes, but since Rust, like C++, instantiates generic functions at specialization
time, this shouldn't be an issue. It just means that, like with C++ templates,
compilation errors concerning the template code can happen at instantiation
time.
In general, this is unavoidable with a mutable reference counting scheme,
because if you have something like this:
struct A<T>
{
v: T
}
impl A<T>
{
fn set_v(&mut self, v: T)
{
self.v = v;
}
}
Then you can allow to call set_v when T is u32, but not when T contains an rc
pointer back to A<T> because that could create a cycle for some values of v.
The alternative is to just disallow programs that have cycles of rc pointers
where at least one of them is mutable, which is less powerful.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
