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.

[ghost]

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.

[ghost]

@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.

[ghost]

@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.

[ghost]

@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!

[ghost]

To be fair, what I described above is already a problem for the borrow checker in that without the special knowledge of particular smart pointers (like Box) it cannot guarantee that dereferencing a smart pointer always returns the same location in memory. So maybe it's worth exploring potential avenues for expressing that guarantee to the compiler.

[Manishearth]

Actually, I don't have enouigh knowledge of the compiler to be able to write a good RfC on this, after probing the issue, sorry :/

[Kimundi]

Could box patterns maybe simply get restricted so that for a given pattern match, the implementation of the matcher only has to call deref() at most once?

[steveklabnik]

Triage: box patterns are now feature gated.

[steveklabnik]

Triage: box patterns are still gated, but doing a grep of the source code:

$ git grep "PatUniq"
src/grammar/parser-lalr.y:| BOX pat                                         { $$ = mk_node("PatUniq", 1, $2); }
$

I'm guessing this is used somewhere, but maybe under a different name or something?

[pnkfelix]

@steveklabnik I think the rename happened, but not the extension to arbitrary box patterns smart pointers

[nikomatsakis]

I think we can close this. The extension to arbitrary "smart pointers" etc feels like an RFC issue to me.