Implement placement-in protocol for relevant data structures

[nagisa]

We currently have the unstable new arrow syntax (<-) for placement-in in nightly with intention to see how people like the syntax/how ergonomic it is/etc. However, it is pretty hard to try the syntax out without having any useful/common data-structures implementing the placement-in protocol and thus it is pretty unlikely for us to collect much feedback on the syntax.

The Placer, Place and InPlace traits should be implemented for following data structures as appropriate:

• Vec (&mut myvec <- value; see this RFC regarding mutable reference) Implement placement-in protocol for Vec #32366
• HashMap through Entry (i.e. mymap.entry(k) <- value) Implement placement-in protocol for HashMap #40390
• BTreeMap through Entry.
• LinkedList Implement placement-in protocol for LinkedList #31696
• BinaryHeap (&mut heap <- value) Implement placement-in protocol for BinaryHeap #39062
• VecDeque (front_place and back_place, like LinkedList) Implement placement-in protocol for VecDeque #40389

It should also be investigated how viable implementing placement protocol is for other std::collections collections and possibly implementing these as well.

Since both placement protocol and placement-in syntax are unstable, there’s no stability hazard.

cc @pnkfelix.

---

I personally feel this issue has tons of potential to help people get acquainted with rust’s standard library (i.e. is in E-easy land) and would be willing to answer any questions (E-mentor) regarding implementation strategies on IRC or the issue itself.

[pnkfelix]

we might consider myvec.back() <- value; rather than myvec <- value;. the main reason I can think of of hand is that there may be issues related to indexing sugars, e.g. ambiguity of mymap[k] <- value; when you have a map with vec values.

[apasel422]

@nagisa BTreeMap is also a candidate through its Entry.

[nagisa]

@apasel422 added to the list.

[nagisa]

Since the LinkedList has been implemented one could use the PR as example when implementing the protocol for other collections.

[notmatt]

@nagisa this looks like something I'd like to take a swing at; would some initial code in a week (±a weekend) be ok?

[nagisa]

Sure!
On Feb 18, 2016 10:12 PM, "Matthew Smillie" notifications@github.com
wrote:

@nagisa https://github.com/nagisa this looks like something I'd like to
take a swing at; would some initial code in a week (±a weekend) be ok?

—
Reply to this email directly or view it on GitHub
#30172 (comment).

[notmatt]

@nagisa quick update: apart from an unexpected shortage of spare time, this is going well. I've mostly been reading/understanding Placer et alia & the LinkedList implmentation. I'm starting with the VecDeque given its broad similarity, but not a lot to show yet.

[pcwalton]

Wanted for WebRender.

[nagisa]

Dear T-libs members. It has been a

• bit more than a year since this issue has been created;
• 3 quarters since Implement placement-in protocol for Vec #32366 where there was a note that there has to be some conventions before this can proceed;
• 1 quarter since Servo expressed their immense interest in this feature;
• 1 quarter since there seemingly was a discussion by T-libs members with no aftermath posted whatsoever.

Perhaps the boring, cold and silent cooldown period after Christmas could be a good time to ponder on whatever you think is the best and report after the vacation?

I’d like to note that gaining experience with placement-in is literally blocking stabilisation of this feature and since nothing implements the placement-in stuff, nobody is using it, ergo not gaining experience. I feel like adding the placement-in impls, be it in an unstable form, is the easiest way to break this loop that’s putting this awesome feature to the cold hands of Ms. Banshee.

[aturon]

@nagisa Thanks for the reminder! It looks like what happened here is that the libs team discussion was posted to the PR rather than the tracking issue.

To recap:

• Collections like Vec which have a clear "default place" can implement the protocol directly, e.g. vec <- item.
• Otherwise standardizing around the convention collection.place_location() <- item seems reasonable. For example vec.place_front() <- item

But then it turned out we can't quite get the desired sweet syntax for Vec yet, so we're proposing using place_location as the convention. PRs along these lines continue to be welcome.

(In terms of priority, placement continues to not be a high priority as far as I'm aware.)

[bluss]

API issue: reusing Vec's placer type allows violating memory safety (writing to the Vec without allocating space). See issue #44637

[bluss]

(Edited: This ended up in the wrong issue, transporting the comment over to the tracking issue for placement new.)

[F001]

I also wonder whether it is useful to implement placement-in protocol for many wrapper types beside collections, such as Option Cell RefCell etc.

[tamird]

Looks like this is headed in the opposite direction now? rust-lang/rfcs#2387

[estebank]

Closing as per removal of placement features in #48333.