On 28 Nov 2025, at 08:24, Duncan Murdoch <[email protected]> wrote:
On 2025-11-27 11:58 a.m., Marcelo Ventura Freire wrote:
If it is not a rhetorical question about a closed issue (if it is, tell me and
I will shut up), this inclusion [1] would be useful (since it was exported and
rewritten so many times by so many people and will keep being), [2] would
create an uniformization (since it was and will be written under so many names
before), [3] would not break stuff (since it is not altering the interface of
any already existing function nor it is overwriting any symbol with a diverse
use), [4] would not be neither a complex nor a tiringsome inclusion (even I
myself could do it in a single 1-line pull request, hypothetically speaking)
and [5] would benefit users all around.
I am not naive to the point of believing that an alteration to the R core would
have few repercussions and surely there must be reasons why it was not done
before.
I don't know why it was added to tools but not exported, but here is my guess:
- A member of R Core agrees with you that this operator is useful. This appears
to have happened in 2016 based on the svn log.
- It already existed in some contributed package, but base packages can't
import anything from non-base packages, so it needed to be added.
- It wasn't exported, because that would break some packages:
- the ones that export something with that name would now receive a check
message about the conflict.
- if those packages stopped exporting it, then any package that imported
from one of them would have to stop doing that, and import it from the base
package instead.
- It is very easy to write your own, or to import one of the existing ones, so
a lot of work would have been generated for not very much benefit.
R Core members try to be careful not to generate work for others unless there's
enough of a net benefit to the community. They are very busy, and many authors
of contributed packages who might be affected by this change are busy too.
But, in the end, this inclusion would be just a seemingly unharmful syntax sugar that could be
shared, like it was with "\" for the reserved word "function", but with waaaay
less work to implement.
The difference there is that it added new syntax, so as far as I know, it didn't
affect any existing package. Personally I don't see that it really offered much
of a benefit (keystrokes are cheap), but lots of people are using it, so I guess
some others would disagree.>
If it is not a dumb proposal, I can just include it in the wishlist of features
in Bugzilla as prescribed in the contributor's page or I can do that PR myself
(if you propose more work to others, the sensible thing to do is at least to
offer yourself to do it, right?). In either case, I create more work to the dev
team, perhaps to different people.
It's hard for you to do the coordination work with all the existing packages
that use a similar operator, so I don't think that's really feasible.
Thanks for taking your time to answer me.
No problem. I'm sitting in an airport waiting for a plane, so any distraction
is a net benefit for me!
Duncan Murdoch>
Marcelo Ventura Freire
Escola de Artes, Ciências e Humanidades
Universidade de São Paulo
Av. Arlindo Bettio, 1000,
Sala Paulo Freire (Sala Coletiva 252), Prédio I1
Ermelino Matarazzo, São Paulo, SP, Brasil
CEP 03828-000
Tel.: (11) 3091-8894
Em qui., 27 de nov. de 2025 às 14:15, Duncan Murdoch <[email protected]
<mailto:[email protected]>> escreveu:
The R sources already contain an operator like that, though it is not
exported. tools:::`%notin%` is defined as
function (x, y)
is.na <http://is.na>(match(x, y))
Several CRAN packages export a similar function, e.g. omnibus, mefa4,
data.table, hutils, etc. So I think if it was exported by R that's a
better name, but since it is easy to write yourself or import from some
other package, why bother?
Duncan Murdoch
On 2025-11-27 9:19 a.m., Marcelo Ventura Freire via R-devel wrote:
> Hello, dear R core developers
>
>
> I have a feature suggestion and, following the orientations in
> https://contributor.r-project.org/rdevguide/chapters/
submitting_feature_requests.html <https://contributor.r-project.org/
rdevguide/chapters/submitting_feature_requests.html>,
> I have searched in Bugzilla to the best of my capabilities for
suggestions
> like the one I have in mind but found no results (however, I can
be wrong).
>
> My idea is including this line
>
> `%!in%` <- function(x, table) match(x, table, nomatch = 0L) == 0L
>
> between lines 39 and 40 of the file "src/library/base/R/match.R".
>
> My objective is to create a "not in" operator that would allow us
to write
> code like
>> value %!in% valuelist
> instead of
>> ! value %in% valuelist
> which is in line with writing
>> value1 != value2
> instead of
>> ! value1 == value2
>
> I was not able to devise any reasonable way that such inclusion
would break
> any already existing heritage code unless that operator would be
defined
> otherwisely and it would improve (however marginally) the
readability of
> future code by its intuitive interpretation and by stitching
together two
> operators that currently stand apart each other.
>
> So, if this suggestion was not already proposed and if it is seen as
> useful, I would like to include it in the wishlist in Bugzilla.
>
> I would appreciate any feedback, be it critic or support, and I
hope I have
> not crossed any communicational rule from the group.
>
> Many thanks! 😄
>
>
>
> Marcelo Ventura Freire
> Escola de Artes, Ciências e Humanidades
> Universidade de São Paulo
> Av. Arlindo Bettio, 1000,
> Sala Paulo Freire (Sala Coletiva 252), Prédio I1
> Ermelino Matarazzo, São Paulo, SP, Brasil
> CEP 03828-000
> Tel.: (11) 3091-8894
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [email protected] <mailto:[email protected]> mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel <https://
stat.ethz.ch/mailman/listinfo/r-devel>
______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
