Implement .name_spec = "inner"
#1995
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #1988
Branched from #1994
To ignore outer names (but use them in error messages), and retain inner names, see #1988 for rationale
Pretty easy implementation for this, and I'm very satisfied that this can function as a
.name_spec
that works for the fallback case as well. None of the others do, which can be a little frustrating sometimes when designing fully generic APIs.There's only one thing to note. In
vec_rbind()
we previously disallowed this:i.e. when you set
.names_to = "id"
to consume thefoo
outer name and promote it to a column name, you can't alsozap()
the row names, which is supposed to zap both the outer and inner parts of the row names.I think this is overly restrictive? I think we should just say "
.name_spec
only receives an outer name when.names_to = NULL
, otherwise the outer name is consumed by the.names_to
behavior". We don't have to restrict the behavior of.name_spec
at all, and it is a little annoying that we do so right now.You should be able to do the rbind call above. It's requesting:
foo
name to an element of a newid
column"row"
row nameI think this is a totally valid use case.
Similarly we are now going to allow all of these valid cases: