lang (syntax | expressions | placement-new)
For details see the summary comment.
Rather than trying to find a clever syntax for placement-new that leverages
the in keyword, instead use the syntax PLACE_EXPR <- VALUE_EXPR.
This takes advantage of the fact that <- was reserved as a token via
historical accident (that for once worked out in our favor).
One sentence: the syntax a <- b is short, can be parsed without
ambiguity, and is strongly connotated already with assignment.
Further text (essentially historical background):
There is much debate about what syntax to use for placement-new.
We started with box (PLACE_EXPR) VALUE_EXPR, then migrated towards
leveraging the in keyword instead of box, yielding in (PLACE_EXPR) VALUE_EXPR.
A lot of people disliked the in (PLACE_EXPR) VALUE_EXPR syntax
(see discussion from RFC 809).
In response to that discussion (and also due to personal preference)
I suggested the alternative syntax in PLACE_EXPR { BLOCK_EXPR },
which is what landed when RFC 809 was merged.
However, it is worth noting that this alternative syntax actually
failed to address a number of objections (some of which also
applied to the original in (PLACE_EXPR) VALUE_EXPR syntax):
While in (place) value is syntactically unambiguous, it looks completely unnatural as a statement alone, mainly because there are no verbs in the correct place, and also using in alone is usually associated with iteration (for x in y) and member testing (elem in set).
As C++11 experience has shown, when it's available, it will become the default method of inserting elements in containers, since it's never performing worse than "normal insertion" and is often better. So it should really have as short and convenient syntax as possible.
I’m not a fan of in
{ }, simply because the requirement of a block suggests that it’s some kind of control flow structure, or that all the statements inside will be somehow run ‘in’ the given (or perhaps, as @m13253 seems to have interpreted it, for all box expressions to go into the given place). It would be our first syntactical construct which is basically just an operator that has to have a block operand.
I believe the PLACE_EXPR <- VALUE_EXPR syntax addresses all of the
above concerns.
Thus cases like allocating into an arena (which needs to take as input the arena itself and a value-expression, and returns a reference or handle for the allocated entry in the arena -- i.e. cannot return unit) would look like:
let ref_1 = arena <- value_expression;
let ref_2 = arena <- value_expression;
compare the above against the way this would look under RFC 809:
let ref_1 = in arena { value_expression };
let ref_2 = in arena { value_expression };
Extend the parser to parse EXPR <- EXPR. The left arrow operator is
right-associative and has precedence higher than assignment and
binop-assignment, but lower than other binary operators.
EXPR <- EXPR is parsed into an AST form that is desugared in much
the same way that in EXPR { BLOCK } or box (EXPR) EXPR are
desugared (see PR 27215).
Thus the static and dynamic semantics of PLACE_EXPR <- VALUE_EXPR
are equivalent to box (PLACE_EXPR) VALUE_EXPR. Namely, it is
still an expression form that operates by:
PLACE_EXPR to a placeVALUE_EXPR directly into the constructed place(See protocol as documented in RFC 809 for more details here.)
This parsing form can be separately feature-gated (this RFC was
written assuming that would be the procedure). However, since
placement-in landed very recently (PR 27215) and is still
feature-gated, we can also just fold this change in with
the pre-existing placement_in_syntax feature gate
(though that may be non-intuitive since the keyword in is
no longer part of the syntactic form).
This feature has already been prototyped, see place-left-syntax branch.
Then, (after sufficient snapshot and/or time passes) remove the following syntaxes:
box (PLACE_EXPR) VALUE_EXPRin PLACE_EXPR { VALUE_BLOCK }That is, PLACE_EXPR <- VALUE_EXPR will be the "one true way" to
express placement-new.
(Note that support for box VALUE_EXPR will remain, and in fact, the
expression (box ()) expression will become unambiguous and thus we
could make it legal. Because, you know, those boxes of unit have a
syntax that is really important to optimize.)
Finally, it would may be good, as part of this process, to actually
amend the text RFC 809 itself to use the a <- b syntax.
At least, it seems like many people use the RFC's as a reference source
even when they are later outdated.
(An easier option though may be to just add a forward reference to this
RFC from RFC 809, if this RFC is accepted.)
The only drawback I am aware of is this comment from nikomataskis
the intent is less clear than with a devoted keyword.
Note however that this was stated with regards to a hypothetical
overloading of the = operator (at least that is my understanding).
I think the use of the <- operator can be considered sufficiently
"devoted" (i.e. separate) syntax to placate the above concern.
See different surface syntax from the alternatives from RFC 809.
Also, if we want to try to make it clear that this is not just
an assignment, we could combine in and <-, yielding e.g.:
let ref_1 = in arena <- value_expression;
let ref_2 = in arena <- value_expression;
Finally, precedence of this operator may be defined to be anything from being less than assignment/binop-assignment (set of right associative operators with lowest precedence) to highest in the language. The most prominent choices are:
Less than assignment:
Assuming () never becomes a Placer, this resolves a pretty common
complaint that a statement such as x = y <- z is not clear or readable
by forcing the programmer to write x = (y <- z) for code to typecheck.
This, however introduces an inconsistency in parsing between let x = and
x =: let x = (y <- z) but (x = z) <- y.
Same as assignment and binop-assignment:
x = y <- z = a <- b = c = d <- e <- f parses as
x = (y <- (z = (a <- (b = (c = (d <- (e <- f))))))). This is so far
the easiest option to implement in the compiler.
More than assignment and binop-assignment, but less than any other operator:
This is what this RFC currently proposes. This allows for various
expressions involving equality symbols and <- to be parsed reasonably and
consistently. For example x = y <- z += a <- b <- c would get parsed as x = ((y <- z) += (a <- (b <- c))).
More than any operator:
This is not a terribly interesting one, but still an option. Works well if
we want to force people enclose both sides of the operator into parentheses
most of the time. This option would get x <- y <- z * a parsed as (x <- (y <- z)) * a.
What should the precedence of the <- operator be? In particular,
it may make sense for it to have the same precedence of =, as argued
in these comments. The ultimate answer here will
probably depend on whether the result of a <- b is commonly composed
and how, so it was decided to hold off on a final decision until there
was more usage in the wild.
2016.04.22. Amended by rust-lang/rfcs#1319 to adjust the precedence.