Rename PatUniq to PatBox and extend support to arbitrary smart pointers

[pcwalton]

Yup.

[ahmedcharles]

Would you mind commenting on what "extend support to arbitrary smart pointers" means? I did the rename, but I imagine that wasn't the most important part of this?

[alexcrichton]

Something like this should also work:

let foo = Rc::new(3);
match foo {
    box n => println!("{}", n),
}

That should also work for things like Gc, Arc, etc.

I'll look into this.

[pnkfelix]

@jakub- do you have someone mentoring you on it? It will probably tie into our allocator story, which remains to be 100% settled.

I don't want to investing a lot of effort into a path that we are not planning on going down.

@pnkfelix Well, for now I was just going to make the box pattern compile down to a deref for arbitrary pointers rather than Box<> pointers specifically. I'd imagine the Deref trait is going to stay regardless of the allocator changes?

[huonw]

Should box patterns go through an RFC? (Just to get the precise semantics (& what's supported/what's not) nailed down.)

[pnkfelix]

@jakub- oh sorry, I misread the title and was thinking of the box (..) expr expression, not of box patterns.

@pnkfelix Right, no worries!

@huonw I agree this could use an RFC. I'll write one up.

[Manishearth]

Is there an RFC for this? If not, I don't mind writing one and maybe starting work on this.

@Manishearth Please go ahead if you're interested!

The reason I hadn't gotten around to writing an RFC is my serious doubts around if allowing box patterns for arbitrary pointers is really feasible and/or a good idea. Essentially, for it to work the deref method would be required to be referentially transparent, something which the compiler cannot guarantee in the general case. Rust used to have a notion of purity for functions that was not well-defined and subsequently removed which in this case would probably be useful to have.

But I'm looking forward to your proposal and maybe it's workable!