Should setnames() produce duplicate column names without warning? #4044

Activity

1. sindribaldur

   changed the title [-]behavior in setnames()[/-] [+]Should setnames() produce duplicate column names without warning?[/+] on Nov 13, 2019
2. jangorecki commented on Nov 29, 2019

   

   jangorecki

   on Nov 29, 2019

   Last edited by jangorecki

   Member

   More actions

   There is a comment

   dups allowed without warning; warn if and when the dup causes an ambiguity

   in

   data.table/R/data.table.R

   Line 2460 in 6f17d18

   # if (anyDuplicated(new)) warning("Some duplicates exist in 'new': ", brackify(new[duplicated(new)])) # dups allowed without warning; warn if and when the dup causes an ambiguity

   is there any ambiguity here?
   not in the first expression, second also seems OK, and third... should we rename both columns to a new name?

   ---

   rather than micromanaging that here I would prefer to have global option to stop if there are dups in column names, at any stage.
3. MichaelChirico

   added

   feature request

   on Jul 14, 2025
4. venom1204 commented on Feb 16, 2026

   

   venom1204

   on Feb 16, 2026

   Last edited by venom1204

   Contributor

   More actions

   Hi @jangorecki,
   I am planning to implement a fix for this issue based on your suggestion to use a centralized approach rather than micromanaging duplicate checks across different functions.
   Proposed Plan:

   • onLoad.R: Register a new global option datatable.warn.duplicate.names (defaulting to FALSE). This ensures backward compatibility for users who rely on the current behavior.
   • utils.R: Add an internal helper warn_if_duplicate_names(). This centralizes the logic so we can easily extend the warning to rbindlist, merge, or setDT in the future without duplicating code.
   • data.table.R: Update setnames() to construct a "preview" of the resulting names and call the utility helper before committing changes.

   if this sounds good i will be happy to proceed with the pr.
5. ben-schwen commented on Feb 17, 2026

   

   ben-schwen

   on Feb 17, 2026

   Last edited by ben-schwen

   Member

   More actions

   My 2 cents on this.

   Maybe we can use something like datatable.unique.names and then options like c("warn", "error", "rename", "off"), where

   • "warn" should return a warning
   • `"error" should return an error
   • "rename" should fix it, e.g. with make.names(, unique=TRUE)
   • "off" should do nothing

   And we can gradually escalate from warning to error and eventually even to rename since one of data.tables "promises" is that it just works
6. venom1204 commented on Feb 25, 2026

   

   venom1204

   on Feb 25, 2026

   Last edited by venom1204

   Contributor

   More actions

   Got it, that makes sense. I’ll implement the policy-based approach (off, warn, error, rename) as suggested and open a PR soon. Thanks for the feedback!

   My 2 cents on this.

   Maybe we can use something like datatable.unique.names and then options like c("warn", "error", "rename", "off"), where

   • "warn" should return a warning
   • `"error" should return an error
   • "rename" should fix it, e.g. with make.names(, unique=TRUE)
   • "off" should do nothing

   And we can gradually escalate from warning to error and eventually even to rename since one of data.tables "promises" is that it just works