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
> <murdoch.duncan at gmail.com <mailto:murdoch.duncan at
gmail.com>> 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]]
> >
> > ______________________________________________
> > R-devel at r-project.org <mailto:R-devel at r-project.org>
mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel <https://
> stat.ethz.ch/mailman/listinfo/r-devel>
>