librustc: Implement placement box for GC and unique pointers.#11055
librustc: Implement placement box for GC and unique pointers.#11055bors merged 1 commit intorust-lang:masterfrom
box for GC and unique pointers.#11055Conversation
There was a problem hiding this comment.
Should the first expression be optional to allow for a better pretty-printing experience?
There was a problem hiding this comment.
Yes, eventually, but right now the non-optional one is parsed the same as ExprUnary for backwards compat.
|
Exciting! |
src/libstd/gc.rs
Outdated
There was a problem hiding this comment.
Shouldn't we call this Gc to match the type name? I don't really care which convention we use, but I guess we ought to be consistent.
There was a problem hiding this comment.
Oh, it's a static, and all caps is the convention.
There was a problem hiding this comment.
On Thu, Jan 09, 2014 at 11:38:28AM -0800, Brian Anderson wrote:
+pub static GC: () = ();
Oh, it's a static, and all caps is the convention.
Just to put some thoughts out there before I forget:
All caps is the convention for constants, but I don't consider Gc or
Heap to be constants, even though they are static values. The
capitalization of static values already varies quite a bit depending
on what kind of static value it is. For example, when one writes:
struct Foo(uint);
one is also declaring a static value, but we don't make the name of
"Foo the type" and "Foo the constructor function" distinct.
Similarly, fn foo() { ... } declares a static value, and yet we
don't write fn FOO() {}. Therefore, I don't see the harm in saying:
static values that are intended to serve as allocators should be named
differently from constants like BUFFER_LENGTH.
|
r+ --- looks good to me.
|
src/libstd/owned.rs
Outdated
There was a problem hiding this comment.
Typo: allocates into no place -> allocates into when no place
|
(also needs a rebase) |
|
Agree we should keep discussing the names HEAP/GC. |
"try this" -> "try" Current help messages contain a mix of "try", "try this", and one "try this instead". In the spirit of rust-lang#10631, this PR adopts the first, as it is the most concise. It also updates the `lint_message_conventions` test to catch cases of "try this". (Aside: rust-lang#10120 unfairly contained multiple changes in one PR. I am trying to break that PR up into smaller pieces.) changelog: Make help messages more concise ("try this" -> "try").
r? @nikomatsakis