We need an core::at_str library

[erickt]

There's no way to convert between a ~str and a @str. We need a library that provides this and other functionality.

[brson]

Or alternately better integration of @Strs and @Vecs into core::str and vec. More abstraction is called for. The at_vec module hasn't been a huge success.

[nikomatsakis]

So, I know that @pcwalton is opposed because it makes the signatures complex (which it does), but making use of static typeclass methods and the builder interface stuff, it is totally plausible to have all methods on iterables generate either ~[] or @[] or even user-defined impls, depending on what the inferencer decides is necessary.

Basically map() (here shown in its most generic form, for any iterable) would look like:

fn map<A, IA: Iterable<A>, B, C: Buildable<B>>(
    input: IA, conv: fn(&A) -> B) -> C
{
    do Buildable::build |push| {
        for input.each |a| {
            push(conv(a));
        }
    }
}

And the Buildable iface would look something like:

type PushFn<T> = &fn(+t: T);
trait Buildable<T> {
    pure fn build(pusher: &pure fn(PushFn<T>)) -> self;
}

And the impl for ~[] would look like:

impl<T> ~[T]: Buildable<T> {
    pure fn build(pusher: &pure fn(PushFn<T>)) -> ~[T] {
        let mut vec = ~[];
        do pusher |elem| {
            // unsafe is needed because this function should appear
            // pure from the outside.  We know it's safe because `vec`
            // does not escape, but the type system doesn't know it...

            unsafe { vec.push(elem); }
        }
        return vec;
    }
}

There are undoubtedly a lot of bugs standing between us and having this work, as well as (at least) one other enhancement that I think would be important. That enhancement is that we probably need some kind of way to help the type inferencer when the required type is underconstrained. Or else we just add type hints. I'm thinking of a situation like this:

for v.map(|e| ...).each |e| { ... }

Here, there is no way for the type inferencer to know what result type map() should have---it just needs to be something iterable. Alternatively, if you did this:

let mapped: ~[T] = v.map(|e| ...);
for mapped.each |e| { ... }

then the type inferencer would know what to do.

The downside of this scheme is that... well... it IS complex. But it'd be nice not to need to define higher-order things likemap() more than once.

Note: Here I've used the "receiver-less" fn notation that we intend to move to, rather than the keyword static that is currently required. I also invoked the "receiver-less" fn by prefixing it with the trait name, as I'd like to do. :)

[jruderman]

Or library functions could generally build ~strs, and Rust could allow casting a ~str to @str.

[jruderman]

Which is #3450

[catamorphism]

I don't think this will break existing code, so clearing the milestone and nominating for milestone 3, feature-complete. I think we need some discussion about the str situation.

[pnkfelix]

accepted for feature complete by analogy with #3450

[pnkfelix]

wontfix, @str should go away.