Phillip Cloud

> s.overlaps would not solve the example use case, would it? Sure, alone it would not. I am suggesting that that is a *composable* piece that when combined with `~s.value(...)`...

> or you add a join mode to a selector (as field, defaulting to intersect) with a .join_as("union") overwrite method, which also takes ("left", "right", "union" or "intersect"). This is...

I'll do a bit of digging around and see how dplyr handles selectors (if it does!) in joins.

🤔 Very interesting. > Are there other operations than join that interact with more than one table? The various set operations: `t.union(s)`/`t.intersect(s)`/`t.difference(s)`. I'm not sure if there are specialized selectors...

> Maybe we would want to stick with an ir.Value based return-type, I think we should, if possible. I don't think we need to worry about preserving the origin table...

Hi @wleescor 👋🏻! Thanks for opening an issue about this. I agree that it's surprising to only have the first group/order chain apply to subsequent window functions. There's at least...

Well, we've got 5.0.0 coming up, seems like as good a time as any to make this change!

Do you have any idea how widespread the use of these types is? TBH I haven't followed whether these nullable types are now the common case or not.

Thanks @jreback! I think we can do the following: 1. Add experimental support for this in 5.0, with an option `use_nullable_dtypes` (?) defaulting to `False` 2. If all goes well,...

The issue with that kind of optionality is that `has_nulls()` will introduce yet another scan of the data. I think this is going to be an all or nothing option,...