rlang 0.3.2

rlang 0.3.1

This patch release polishes the new backtrace feature introduced in rlang 0.3.0 and solves bugs for the upcoming release of purrr 0.3.0. It also features as_label() and as_name() which are meant to replace quo_name() in the future. Finally, a bunch of deparsing issues have been fixed.

Backtrace fixes

as_label() and as_name()

The new as_label() and as_name() functions should be used instead of quo_name() to transform objects and quoted expressions to a string. We have noticed that tidy eval users often use quo_name() to extract names from quosured symbols. This is not a good use for that function because the way quo_name() creates a string is not a well defined operation.

For this reason, we are replacing quo_name() with two new functions that have more clearly defined purposes, and hopefully better names reflecting those purposes. Use as_label() to transform any object to a short human-readable description, and as_name() to extract names from (possibly quosured) symbols.

Create labels with as_label() to:

We expect as_label() to gain additional parameters in the future, for example to control the maximum width of a label. The way an object is labelled is thus subject to change.

On the other hand, as_name() transforms symbols back to a string in a well defined manner. Unlike as_label(), as_name() guarantees the roundtrip symbol -> string -> symbol.

In general, if you don’t know for sure what kind of object you’re dealing with (a call, a symbol, an unquoted constant), use as_label() and make no assumption about the resulting string. If you know you have a symbol and need the name of the object it refers to, use as_name(). For instance, use as_label() with objects captured with enquo() and as_name() with symbols captured with ensym().

Note that quo_name() will only be soft-deprecated at the next major version of rlang (0.4.0). At this point, it will start issuing once-per-session warnings in scripts, but not in packages. It will then be deprecated in yet another major version, at which point it will issue once-per-session warnings in packages as well. You thus have plenty of time to change your code.

Minor fixes and features

rlang 0.3.0

Breaking changes

The rlang API is still maturing. In this section, you’ll find hard breaking changes. See the life cycle section below for an exhaustive list of API changes.


The changes for this version are organised around three main themes: error reporting, tidy eval, and tidy dots.

Conditions and errors

Tidy dots

Tidy eval



Other improvements and fixes


Soft-deprecated functions and arguments

rlang 0.3.0 introduces a new warning mechanism for soft-deprecated functions and arguments. A warning is issued, but only under one of these circumstances:

In addition, deprecation warnings appear only once per session in order to not be disruptive.

Deprecation warnings shouldn’t make R CMD check fail for packages using testthat. However, expect_silent() can transform the warning to a hard failure.



Deprecated functions and arguments

Deprecated functions and arguments issue a warning inconditionally, but only once per session.

Defunct functions and arguments

Defunct functions and arguments throw an error when used.

Functions and arguments in the questioning stage

We are no longer convinced these functions are the right approach but we do not have a precise alternative yet.

rlang 0.2.2

This is a maintenance release that fixes several garbage collection protection issues.

rlang 0.2.1

This is a maintenance release that fixes several tidy evaluation issues.

rlang 0.2.0

This release of rlang is mostly an effort at polishing the tidy evaluation framework. All tidy eval functions and operators have been rewritten in C in order to improve performance. Capture of expression, quasiquotation, and evaluation of quosures are now vastly faster. On the UI side, many of the inconveniences that affected the first release of rlang have been solved:

See the first section below for a complete list of changes to the tidy evaluation framework.

This release also polishes the rlang API. Many functions have been renamed as we get a better feel for the consistency and clarity of the API. Note that rlang as a whole is still maturing and some functions are even experimental. In order to make things clearer for users of rlang, we have started to develop a set of conventions to document the current stability of each function. You will now find “lifecycle” sections in documentation topics. In addition we have gathered all lifecycle information in the ?rlang::lifecycle help page. Please only use functions marked as stable in your projects unless you are prepared to deal with occasional backward incompatible updates.

Tidy evaluation



Various features


API changes

The rlang API is maturing and still in flux. However we have made an effort to better communicate what parts are stable. We will not introduce breaking changes for stable functions unless the payoff for the change is worth the trouble. See ?rlang::lifecycle for the lifecycle status of exported functions.

Breaking changes

Upcoming breaking changes

rlang 0.1.6

rlang 0.1.4

rlang 0.1.2

This hotfix release makes rlang compatible with the R 3.1 branch.

rlang 0.1.1

This release includes two important fixes for tidy evaluation:

New functions:

UI improvements:


rlang 0.1.0

Initial release.