Deprecate ScalarUDF::is_nullable

[findepi]

ScalarUDFImpl::is_nullable is deprecated since d3f1c9a. The ScalarUDF's wrapper also needs deprecation to allow eventually removing the deprecated ScalarUDFImpl::is_nullable.

cc @Blizzara

[alamb]

THANK YOU

[Blizzara]

Thanks! The deprecation is sure an improvement, but I wonder if overall this is_nullable -> return type from args change suffers from the same issue as the earlier ones, namely that if a user implements a custom UDF overriding the is_nullable, they don’t see the deprecation warning and so their compiler won’t likely warn them to switch to the new one. If I remember correctly, the ”best” way I could figure out for these cases where

• a new function is introduced in the (Scalar)UdfImpl interface and switched to internally, and
• the new function does not by default delegate to the previously-internally-used function,
  would be to just remove the old function completely from the interface. Otherwise downstream implementors won’t get compile-time warnings, which is unfortunate. Obviously full removal has its own downsides too…

(I may be also a bit rusty in my thinking, haven’t been working on this for a while anymore now.)

[findepi]

the new function does not by default delegate to the previously-internally-used function

Typically the new function delegates to the old one and the old one gets deprecated.

If that's not possible, adding such new function is a breaking API change. In such case, graceful deprecation of the old function doesn't help, and actually makes situation worse, as you said -- no compiler's help.

Given exactly this was the case with ScalarUDFImpl::is_nullable in d3f1c9a, I suggest removal of the is_nullable function. However, I don't have full context and I am not the author of that change.
@Blizzara do you want to make a follow-on PR with the removal?

[alamb]

I agree that simply removing the is_nullable method, even though it is a breaking API, might be the least confusing course of action

now that we have an Upgrade Guide, we have a place to provide more context for these changes too so I think thier impact is less jarring / seemingly arbitrary