Should DbFunctions extensions be annotated with [NotNull] or [CanBeNull]?

[roji]

When we expose functions via DbFunctions extensions, we annotate parameters for nullability, but it isn't clear what our policy should be.

• On the one hand, (most) SQL functions accept null and propagate, so it's technically OK to pass in nulls.
• But on the other hand, we have functions which return value types (e.g. Like), so they can't return null (should they? should they throw for null?)
• Another point is that this creates a split between buit-in functions and DbFunctions extensions (the former don't accept null where it doesn't make sense, the latter do). This isn't a strong argument because the latter represent the database operation much more closely than the former.
• Either way we may need to do some cleanup around this: Like has [CanBeNull] (and returns non-nullable bool), but SQL Server's free-text extensions accept [NotNull] (is there an actual behavioral difference).

[smitpatel]

Assigning to @roji to present in design meeting. (not urgent)