box and in expressions (tracking issue for RFC 809)
#22181
Labels
B-RFC-approved
Blocker: Approved by a merged RFC but not yet implemented.
C-tracking-issue
Category: An issue tracking the progress of sth. like the implementation of an RFC
T-lang
Relevant to the language team, which will review and decide on the PR/issue.
Comments
This was referenced Feb 12, 2015
steveklabnik
added
the
B-RFC-approved
This was referenced Feb 16, 2015
Manishearth
added a commit
to Manishearth/rust
that referenced
this issue
Feb 17, 2015
…-expansion, r=huonw Pass features along during expansion Use the set of passed features to detect uses of feature-gated macros without the corresponding feature enabled. Fix rust-lang#22234. ---- Also, the framework this add (passing along a reference to the features in the expansion context) is a necessary precursor for landing a properly feature-gated desugaring-based overloaded-`box` and placement-`in` (rust-lang#22181). ---- This is fixing a bug, but since there might be code out there that is unknowingly taking advantage of that bug, I feel obligated to mark this as a: [breaking-change]
bombless
added a commit
to bombless/rust
that referenced
this issue
Feb 23, 2015
…loc-and-free, r=steveklabnik Revise `lang_item` demo to something unrelated to `Box` impl Precursor for landing overloaded-`box`, since that will decouple the `box` syntax from the exchange heap (and should eliminate the use of the two aforementioned lang items). Instead, the new demonstration program shows a definition of the `panic_bounds_check` lang item. (We do not have that many procedural lang-items to choose from, which is a good sign for our efforts to decouple the compiler from the runtime!) ---- Precursor for overloaded-`box` and placement-`in`; see Issue rust-lang#22181.
bors
added a commit
that referenced
this issue
Jun 3, 2015
Hack the move_val_init intrinsic to trans directly into the destination address. This is to remove an intermediate (and unnecessary) alloca on the stack that one otherwise suffers when using this intrinsic. This is part of the `box` protocol work; in particular, this is meant to address the `ptr::write` codegen issues alluded to at this comment: #22086 (comment) cc #22181
This was referenced Jun 7, 2015
bors
added a commit
that referenced
this issue
Jul 24, 2015
…akis
Macro desugaring of `in PLACE { BLOCK }` into "simpler" expressions following the in-development "Placer" protocol.
Includes Placer API that one can override to integrate support for `in` into one's own type. (See [RFC 809].)
[RFC 809]: https://github.com/rust-lang/rfcs/blob/master/text/0809-box-and-in-for-stdlib.md
Part of #22181
Replaced PR #26180.
Turns on the `in PLACE { BLOCK }` syntax, while leaving in support for the old `box (PLACE) EXPR` syntax (since we need to support that at least until we have a snapshot with support for `in PLACE { BLOCK }`.
(Note that we are not 100% committed to the `in PLACE { BLOCK }` syntax. In particular I still want to play around with some other alternatives. Still, I want to get the fundamental framework for the protocol landed so we can play with implementing it for non `Box` types.)
----
Also, this PR leaves out support for desugaring-based `box EXPR`. We will hopefully land that in the future, but for the short term there are type-inference issues injected by that change that we want to resolve separately.
alexcrichton
added
the
T-lang
Mark-Simulacrum
added
C-tracking-issue
SimonSapin
pushed a commit
to aidanhs/rust
that referenced
this issue
Apr 3, 2018
|
Placement new is imminently about to be/has been removed as an unstable feature and the RFCs unaccepted. The approved/merged PR is at #48333 and the tracking issues were at #22181 (this issue) and #27779. Note that this does not affect box syntax. You can find the summary comment at #27779 (comment). Find the internals thread where you can discuss this more at https://internals.rust-lang.org/t/removal-of-all-unstable-placement-features/7223. Please add any thoughts there. |
bors
added a commit
that referenced
this issue
Apr 4, 2018
…sakis Remove all unstable placement features Closes #22181, #27779. Effectively makes the assortment of placement RFCs (rust-lang/rfcs#470, rust-lang/rfcs#809, rust-lang/rfcs#1228) 'unaccepted'. It leaves `box_syntax` and keeps the `<-` token as recognised by libsyntax. ------------------------ I don't know the correct process for unaccepting an unstable feature that was accepted as an RFC so...here's a PR. Let me preface this by saying I'm not particularly happy about doing this (I know it'll be unpopular), but I think it's the most honest expression of how things stand today. I've been motivated by a [post on reddit](https://www.reddit.com/r/rust/comments/7wrqk2/when_will_box_and_placementin_syntax_be_stable/) which asks when these features will be stable - the features have received little RFC-style design work since the end of 2015 (~2 years ago) and leaving them in limbo confuses people who want to know where they're up to. Without additional design work that needs to happen (see the collection of unresolved questions later in this post) they can't really get stabilised, and I think that design work would be most suited to an RFC rather than (currently mostly unused) experimental features in Rust nightly. I have my own motivations - it's very simple to 'defeat' placement in debug mode today and I don't want a placement in Rust that a) has no guarantees to work and b) has no plan for in-place serde deserialisation. There's a quote in [1]: "Ordinarily these uncertainties might lead to the RFC being postponed. [The RFC seems like a promising direction hence we will accept since it] will thus give us immediate experience with the design and help in determining the best final solution.". I propose that there have been enough additional uncertainties raised since then that the original direction is less promising and we should be think about the problem anew. (a historical note: the first mention of placement (under that name - uninit pointers were earlier) in an RFC AFAIK is [0] in late 2014 (pre-1.0). RFCs since then have built on this base - [1] is a comment in Feb 2015 accepting a more conservative design of the Place* traits - this is back when serde still required aster and seemed to break every other nightly! A lot has changed since then, perhaps placement should too) ------------------------ Concrete unresolved questions include: - making placement work in debug mode [7] - making placement work for serde/with fallible creation [5], [irlo2], [8] - trait design: - opting into not consuming the placer in `Placer::make_place` - [2] - trait proliferation - [4] (+ others in that thread) - fallible allocation - [3], [4] (+ others in that thread) - support for DSTs/unsized structs (if at all) - [1], [6] More speculative unresolved questions include: - better trait design with in the context of future language features [irlo1] (Q11), [irlo3] - interaction between custom allocators and placement [irlo3] [0] rust-lang/rfcs#470 [1] rust-lang/rfcs#809 (comment) [2] rust-lang/rfcs#1286 [3] rust-lang/rfcs#1315 [4] #27779 (comment) [5] #27779 (comment) [6] #27779 (comment) [7] #27779 (comment) [8] rust-lang/rfcs#1228 (comment) [irlo1] https://internals.rust-lang.org/t/placement-nwbi-faq-new-box-in-left-arrow/2789 [irlo2] https://internals.rust-lang.org/t/placement-nwbi-faq-new-box-in-left-arrow/2789/19 [irlo3] https://internals.rust-lang.org/t/lang-team-minutes-feature-status-report-placement-in-and-box/4646
Robbepop
pushed a commit
to Robbepop/rust
that referenced
this issue
Apr 8, 2018
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Tracking issue for rust-lang/rfcs#809. This should be filled out with TODO items. Note that in this case there are some unsettled design questions to be resolved as well.
To do:
indesugaring implementationboxdesugaring implementationlibstdAPIs to supportinlibstdAPIs to supportboxin_inexpr as Box<_>when expectingBox<Trait>? #22221, Cannot dox as Box<[T]>forx: Box<[T; k]>#22403, Could type inference insert coercions to accommodate box desugaring? #22405)Unresolved questions:
box(was Precedence ofboxis possibly wrong #21192)The text was updated successfully, but these errors were encountered: