[Rd] Feature suggestion

Duncan Murdoch murdoch@dunc@n @end|ng |rom gm@||@com
Thu Nov 27 20:24:04 CET 2025 

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>
>

More information about the R-devel mailing list