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. 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. 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 >
>>>>> Simon Urbanek >>>>> on Fri, 28 Nov 2025 12:09:46 +1300 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. 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. > 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 I tend to agree with Marcelo (and Simon IIUC) that we R-core should add "it" (for my taste definitely %nin% or %notin% rather than %!in%) I think it was not directly mentioned that quite a few CRAN packages define %nin% but (many / some) do not export it; I had added it to Matrix a while ago, in 2009, (not exported "of course"), for the obvious syntactic sugar, `%nin%` <- function (x, table) is.na(match(x, table)) but it seems a package co-author did not like it particularly and removed it as "unused" in Summer 2023. As `%in%` is in {base}, this should consequentally also be part of {base}, whereas some people make a valid point that {base} should rather be kept minimal, and things like this should rather be put in {utils}. IIRC, this was actually the (lame!) reason I never brought it up inside R-core. Martin >> 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
>>>>> 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 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
On 2025-11-27 6:09 p.m., Simon Urbanek wrote:> 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. > > 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.I agree with both points. I generally use inefficient and unnecessary parens, i.e. `foo[!(foo %in% baz)]`.> 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.If someone is willing to put up with the fallout from the "masked" messages, then I'd also be in favour. (And I'd choose %notin% rather than %!in% or %nin%, but whoever is willing to do the work should make that choice.) > (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). Or depend on the backports package. Duncan Murdoch> > 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 >> >