Summary
As a tibblify user, in order to convert incoming data to the expected form, I would like to accept any value that can reasonably be coerced to the expected value.
Details
Right now, incoming data sometimes fails to tibblify even though it's BASICALLY in the correct format. For example, if data is loaded in as character (by {yaml} or {jsonlite}, for example), but it's supposed to be integer, even "1" won't properly vctrs::vec_cast() to the desired format.
Instead of the strict casting rules of vctrs::vec_cast(), let's instead use the "accept it as long as no information is lost" rules from stbl::to_*().
This also applies to the .fill argument (which might need its own ticket).
TODO: ADD CONCRETE EXAMPLES OF SURPRISING FAILURES
Related issues
Summary
Details
Right now, incoming data sometimes fails to tibblify even though it's BASICALLY in the correct format. For example, if data is loaded in as character (by {yaml} or {jsonlite}, for example), but it's supposed to be integer, even "1" won't properly
vctrs::vec_cast()to the desired format.Instead of the strict casting rules of
vctrs::vec_cast(), let's instead use the "accept it as long as no information is lost" rules fromstbl::to_*().This also applies to the
.fillargument (which might need its own ticket).TODO: ADD CONCRETE EXAMPLES OF SURPRISING FAILURES
Related issues
ptype_inner#230 (explicitly say what incoming types should be acceptable)tibblify()? #233 (argument to telltibblify()to be ok with missing pieces)filled #231 (.fill_typesarg to apply.fillin more cases; would be much more usable if we didn't choke on.fillas much)