When using `separate_wider_delim()` function remove `sf` class and returns `tibble`

[benjaminhlina]

When using separate_wider_delim() with a sf object, the function misbehaves and returns a tibble. If using separate() the class of the sf object is retained. The same issue was documented in issue tidyverse/tidyr#1495 but no reprex was provided. I had originally made the issue report on the {tidyr} repo, see tidyverse/tidyr#1498, but was recently informed that is likely due to an issues with {sf} not supporting these newer versions of separate_ functions. This is using v1.3.0 of {tidyr} and {sf} v1.0-15 and see reprex.

# load packages 
suppressPackageStartupMessages({
  library(crawl) # loaded for example sf object 
  library(sf) # load sf 
  library(tidyr) # load for separate functions  
})

# load harbour seal data 
data("harborSeal_sf")

# check out the sf object 
class(harborSeal_sf)
#> [1] "sf"         "data.frame"
# make up fake column to separate 

harborSeal_sf$fake <- "test_1"
# now use separate_wide_delim 

error <- harborSeal_sf |>
  separate_wider_delim(cols = fake, names = c("fake", "num"), delim = "_")
class(error)
#> [1] "tbl_df"     "tbl"        "data.frame"
# returns tibble not an sf object so it changes the object's class 

# if we use separate it keeps the objects class 
no_error <- harborSeal_sf |>
  separate(col = fake, into = c("fake", "num"), sep = "_")

class(no_error)
#> [1] "sf"         "data.frame"

^{Created on 2024-03-14 with reprex v2.1.0}

[olivroy]

Since the function uses tidyr::unpack() internally, we'd need to wait for tidyr to make pack()/ unpack() S3 methods and sf could provide its own method then. Not much sf can do without underlying S3 method.

Would have to wait for tidyverse/tidyr#1372 to be merged

Edit: there would still be work required in sf afterwards to define pack(<sf>) and unpack(<sf>)

[elipousson]

I shared the same comment on the PR for tidyr but I just wanted to flag that these random-feeling points of incompatibility between sf and the tidyverse are pretty frustrating to teach!

The "sticky" geometry columns sticks most of the time but not if.... . FWIW - I assembled a reference for my students last year and just updated it to include this issue: https://gist.github.com/elipousson/d423349f98b4afd35920afd672ad2617

[benjaminhlina]

Given that this issue is deep in a PR related to pack() and unpack() I use separate() with any {sf} object considering the behaviour is consistent. It is annoying and confusing for students to learn a special case scenario, i.e., with most objects use separate _wider_() or separate_longer_() but with {sf} objects use separate(), but that's my general use of the functions currently.

[edzer]

The "sticky" geometry columns sticks most of the time but not if....

FWIW - the proposal (or experiment) in #2131 might have developer advantages, but IMO would make it much harder to understand from the user side when geometries are sticky, and when they aren't.