> Date: Fri, 28 Nov 2025 10:19:19 +0100
> From: Kurt Hornik<Kurt.Hornik at wu.ac.at>
>
>>>>>> 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?
>
I would tend to prefer
`%notin%` <- function (x, table) match(x, table, nomatch = 0L) == 0L
so that it is clear also from the body that it is essentially a negation
of '%in%':
`%in%` <- function (x, table) match(x, table, nomatch = 0L) > 0L
For a new user, maybe that is helpful. And the 'nomatch = 0L' usage
will
be familiar already to users who have seen { union, intersect, setdiff },
the set ops.
As for the demise of Matrix:::`%nin%`, mentioned elsewhere by Martin, it
would seem that that package author now finds themself on the wrong side
of history. :-)
Mikael
> 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 at
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 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>
>>>>
>>> ______________________________________________
>>> R-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel