Improve helpfulness of warning message during on-assignment type coer…

[MichaelChirico]

…cion.

Original tweet & some discussion here:

https://twitter.com/sarahbeeysian/status/1021359529789775872

[franknarf1]

Maybe consider changing tone instead of removing the sentence? Like "Setting the column type as intended up front is the best way to get around this if your RHS has the correct type." or something.

Fwiw, for me...

set the column type correctly up front

... was the most useful part of the message as a new user and probably something I wouldn't think of from reading the new message.

inspect your initial LHS types and be sure they're as expected

... gets at the point too indirectly and no longer contains a recommended fix.

I don't find the twitter complaint ("it's rude because I know better already") convincing as an argument to remove it when other users might know less than they do.

---

Also, the first pitfall you highlight

A common source of this error is mismatch of return types when assigning by group, especially in edge cases.

...has its own (error) message already:

library(data.table)
DT = data.table(a = 1:2)
DT[, v := if (.GRP==1L) "a" else 1L, by=a]
> Error in `[.data.table`(DT, , `:=`(v, if (.GRP == 1L) "a" else 1L), by = a) : 
>   Type of RHS ('integer') must match LHS ('character'). To check and coerce would impact performance too much for the fastest cases. Either change the type of the target column, or coerce the RHS of := yourself (e.g. by using 1L instead of 1)

Also, you refer to it as "this error", though it is a warning, which may be confusing.

[mattdowle]

Please @franknarf1 and @MichaelChirico review latest refinement before merge. (The drop down under reviewers won't let me pick either of you. Michael because you submitted the PR I guess and Frank because you're not a project member it seems?! But you can both add your reviews I believe.)

[franknarf1]

Looks good, but the last sentence of the new message refers to class instead of type (comment further down).

(I've never used the github review interface, so please let me know if I've made a mistake. Thanks)

[franknarf1]

Column types can be observed with print(x,class=TRUE) and sapply(x,class).

Some users won't know types for non-atomic classes (integer = IDate, factor; double = Date). Could change sapply(x,class) to sapply(x,typeof), but I'm not sure how to change the reference to print. Maybe some rewording or an extra sentence could work. Alternately, maybe print could have another option, like verbose = TRUE that prints maximal info (somewhat substituting for str and similar to tables()):

library(data.table)
DT = data.table(id = 1:2, d = as.IDate(Sys.Date()) + 0:1)
setkey(DT, id)
setindex(DT, d, id)

print(DT, verbose = TRUE) # fake code
#       id          d
#    <int>     <IDat>
#               <int>
# 1:     1 2018-08-10
# 2:     2 2018-08-11
# 
# key: id
# indices: 
# - d, id

(... Also displaying new statistics from #2879)

Anyway, I guess the type/class distinction will only matter in rare cases, like...

library(data.table)
DT = data.table(id = 1:2, d = as.IDate(Sys.Date()) + 0:1)

DT[1, d := "1999-01-01"] 
# gets coerced to NA_integer_

DT[1, d := 1999-01-01] 
# worse, if forgetting quotes and class/type, it gets silently handled as an int

In contrast, sub-assigning a character to a factor works as expected.

[MichaelChirico]

Awesome! Much more thorough overhaul 👍