Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement placement-in protocol for relevant data structures #30172

Closed
5 of 6 tasks
nagisa opened this issue Dec 2, 2015 · 15 comments
Closed
5 of 6 tasks

Implement placement-in protocol for relevant data structures #30172

nagisa opened this issue Dec 2, 2015 · 15 comments
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. E-help-wanted Call for participation: Help is requested to fix this issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. P-medium Medium priority T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@nagisa
Copy link
Member

nagisa commented Dec 2, 2015

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:

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
Copy link
Member

pnkfelix commented Dec 2, 2015

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
Copy link
Contributor

@nagisa BTreeMap is also a candidate through its Entry.

@nagisa
Copy link
Member Author

nagisa commented Dec 4, 2015

@apasel422 added to the list.

@steveklabnik steveklabnik added the E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. label Dec 7, 2015
@nagisa
Copy link
Member Author

nagisa commented Feb 17, 2016

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

@notmatt
Copy link

notmatt commented Feb 18, 2016

@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
Copy link
Member Author

nagisa commented Feb 18, 2016

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
Copy link

notmatt commented Feb 28, 2016

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

@alexcrichton alexcrichton added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. B-unstable Blocker: Implemented in the nightly compiler and unstable. labels Mar 8, 2016
@pcwalton
Copy link
Contributor

pcwalton commented Aug 8, 2016

Wanted for WebRender.

@nagisa
Copy link
Member Author

nagisa commented Dec 12, 2016

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.

@brson brson added E-help-wanted Call for participation: Help is requested to fix this issue. P-medium Medium priority labels Dec 19, 2016
@aturon
Copy link
Member

aturon commented Dec 19, 2016

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

bors added a commit that referenced this issue Jan 7, 2017
Implement placement-in protocol for `Vec`

Follow-up of #32366 per comment at #30172 (comment), updating to latest rust, leaving @apasel422 as author and putting myself as committer.

I've removed the implementation of `push` in terms of place to make this PR more conservative.
bors added a commit that referenced this issue Jan 20, 2017
Implement placement-in protocol for `BinaryHeap`

Related to #30172, and loosley based on #38551.

At the moment, this PR is in a pretty rough state, but I wanted to get some feedback to see if I'm going in the right direction.

I hope the Mentor label of #30172 is still applicable, even though it's a year old 😄
arielb1 pushed a commit to arielb1/rust that referenced this issue Mar 9, 2017
Implement placement-in protocol for `VecDeque`

CC rust-lang#30172

r? @nagisa
alexcrichton added a commit to alexcrichton/rust that referenced this issue Mar 10, 2017
Implement placement-in protocol for `VecDeque`

CC rust-lang#30172

r? @nagisa
alexcrichton pushed a commit to arielb1/rust that referenced this issue Mar 10, 2017
Implement placement-in protocol for `VecDeque`

CC rust-lang#30172

r? @nagisa
alexcrichton added a commit to alexcrichton/rust that referenced this issue Mar 10, 2017
Implement placement-in protocol for `VecDeque`

CC rust-lang#30172

r? @nagisa
arielb1 pushed a commit to arielb1/rust that referenced this issue Mar 10, 2017
Implement placement-in protocol for `VecDeque`

CC rust-lang#30172

r? @nagisa
arielb1 pushed a commit to arielb1/rust that referenced this issue Mar 10, 2017
Implement placement-in protocol for `VecDeque`

CC rust-lang#30172

r? @nagisa
arielb1 pushed a commit to arielb1/rust that referenced this issue Mar 10, 2017
Implement placement-in protocol for `VecDeque`

CC rust-lang#30172

r? @nagisa
alexcrichton added a commit to alexcrichton/rust that referenced this issue Mar 11, 2017
Implement placement-in protocol for `VecDeque`

CC rust-lang#30172

r? @nagisa
alexcrichton added a commit to alexcrichton/rust that referenced this issue Mar 11, 2017
Implement placement-in protocol for `VecDeque`

CC rust-lang#30172

r? @nagisa
frewsxcv added a commit to frewsxcv/rust that referenced this issue Mar 12, 2017
Implement placement-in protocol for `HashMap`

CC rust-lang#30172

r? @nagisa
@Mark-Simulacrum Mark-Simulacrum added the C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. label Jul 22, 2017
@bluss
Copy link
Member

bluss commented Sep 16, 2017

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

@bluss
Copy link
Member

bluss commented Sep 16, 2017

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

@F001
Copy link
Contributor

F001 commented Jan 15, 2018

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
Copy link
Contributor

tamird commented Apr 8, 2018

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

@estebank
Copy link
Contributor

Closing as per removal of placement features in #48333.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. E-help-wanted Call for participation: Help is requested to fix this issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. P-medium Medium priority T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests