[Rd] Feature suggestion: %!in%

Fri Nov 28 10:19:19 CET 2025

>>>>> Simon Urbanek writes:

> Given that the args of tools:::%notin% don’t match %in% I'd say it was
> just a local use more than any deep thought about general use. 

Actually, I simply never liked 'table' in %in% or match itself, so I
took 'y' instead :-)

> Personally, I really like the idea of %notin% because it is very often
> that you start typing foo[foo %in% and then realise you want to invert
> it and the preceding negation is then cognitively sort of in the wrong
> place (reads like "not foo"). I also like %notin% better than %!in%
> because I think a salad of special characters makes things harder to
> read, but that may be just subjective.

Same from here.  So add

  `%notin%` <- function (x, table) is.na(match(x, table))

to base?

Best
-k

> And to your 'why bother' question - I do think it’s better to
> standardise common operators in core rather than have packages
> re-define it each time. And certainly just importing something that
> trivial from another package is a bad idea given the dependency
> implications. (On the flip side: if you start using it you need to
> depend on recent R which may not be feasible in some environments, but
> then if that was always the argument we’d never add anything new :P).

> Cheers,
> Simon

>> On 28 Nov 2025, at 08:24, Duncan Murdoch <murdoch.duncan using gmail.com> 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 <murdoch.duncan using gmail.com <mailto:murdoch.duncan using 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 using r-project.org <mailto:R-devel using r-project.org> mailing list
>>> > https://stat.ethz.ch/mailman/listinfo/r-devel <https://
>>> stat.ethz.ch/mailman/listinfo/r-devel>
>>> 
>> 
>> ______________________________________________
>> R-devel using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 

> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel