Don't dispatch [.data.frame if !cedta(); warn/message instead
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Start by tracing how cedta() controls dispatch between [.data.table and [.data.frame, paying particular attention to the missing(j) case. Compare the warning or message proposal with the alternatives involving := and by=, and define done as an agreed behavior for failed cedta() detection that avoids inscrutable dispatch.
Written by the indexing model from the issue text.
Description
I have come across a decent number of inscrutable (to the untrained eye) bugs where [ is called on a data.table, but cedta() fails and [.data.frame is dispatched. But the original code, to the naked eye, was clearly intended as a data.table query. Debugging this can be extremely confusing to a first-timer, but of course by now I've seen "Error in [.data.frame" enough times to immediately guess "this is a cedta() failure" without even seeing the underlying code.
I think we should consider whether dispatching [.data.frame is really prudent when cedta() fails. I think a better behavior could be throwing a warning (or message) like "hey, we couldn't determine for sure that you intended to use [.data.table here, but we're doing it anyway", with possible diagnoses/recommendations. Another approach in this vein is to be "smarter" about guessing "oh yeah, this is a data.table query", e.g. if := is used, or if by= (or other [.data.table-but-not-[.data.frame argument) is supplied.
On a deeper level, I wonder whether checking cedta() for [ is even necessary to begin with. {data.table} has been around for nearly 20 years -- it's well-known within the R ecosystem. I'm fairly confident that any LLM can classify a [ query and tell a reader "this is using {data.table}, here's how it works". We have also invested a lot of effort in making [.data.table behave like [.data.frame in most cases.
The only case I can think of where "used [.data.table when [.data.frame was intended" can cause issues would be DF[i], where for data.table that's "take rows i" vs. for data.frame that's "take columns i". I suppose that could cause a subtle bug but it seems to me the resulting bug would be obvious (i.e., most importantly, it should not lead to silent wrong results). Maybe we can retain the cedta() check only when missing(j).
- Dominant language
- R
- Stars
- 3.9k
- Forks
- 1.1k
- Avg merge
- 14h 4m
- Merged PRs (30d)
- 4
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Rdatatable/data.table
-
as.data.table() recurses without end on a survival::Surv object (or any data.frame carrying one) Open
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Rdatatable/data.table#7887 ·
-
consistency tests
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Rdatatable/data.table#7853 · 3 comments ·
-
internals
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Rdatatable/data.table#6938 · 1 comment ·
-
encoding fread
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Rdatatable/data.table#5179 · 8 comments ·
-
documentation programming
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Rdatatable/data.table#3199 · 3 comments ·
All issues in Rdatatable/data.table
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
r-lib/pkgdepends#485 · 3 comments ·
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
-
beginners blocker
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
enviPathR OpenBuild Error Build OK Build Warning policies-accepted pre-review precheck-passed
Difficulty 1/5 Under an hour Newbie friendliness 84/100
Bioconductor/BiocContributions#207 · 6 comments ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
datacarpentry/semester-biology#1255 ·