On Wed, Dec 4, 2013 at 4:17 PM, Isaac Dupree
<m...@isaac.cedarswampstudios.org> wrote:
> On 12/04/2013 02:09 PM, Michael Woerister wrote:
>>>>
>>>> Is it
>>>> possible for the structure to be parametrized on smart pointer?
>>>
>>>
>>> Not without higher kinded types (which eventually we do want--so the
>>> answer is "not yet").
>>
>>
>> And then we can define a container type, using the generic reference type:
>>
>> struct Container<T, TRef, TRefFactory> {
>> items: ~[TRef],
>> reference_factory: TRefFactory
>> }
>
>
> Clever solution! In the cons list, it needs to be a reference to Node<T>,
> not to T. Every persistent container library would have to expose its node
> type and take as a parameter an allocator for its Node<T>. Simplified
> example:
>
> enum Node<T, TNodeRef> {
> Nil,
> Cons(T, TNodeRef)
> }
>
> type IntList = Rc<Node<int, IntList>>;
>
> But that is an infinite type and, as such, does not compile. Instead using
>
> struct IntList(Rc<Node<int, IntList>>);
>
> works and could implement the necessary traits. Or better,
>
> struct RcList<T>(Rc<Node<T, RcList<T>>>);
>
> Ooh, this is within the realm of maybe being reasonable. A persistent data
> structure module could provide RcList and ArcList versions. Is performance
> affected by the use of traits for this strategy, or does the way Rust
> generics are compiled make that a non-issue? Are there other reasons this
> is a terrible idea? :)
>
> -Isaac
Generics are equivalent to substituting all of the type parameters
with the concrete type by hand. Specialized code is generated for each
set of type parameters with removing the duplication left up to LLVM
(`mergefunc` is close to being completely stable).
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
