Problems with checking if a value is (can be converted) to a `Column`

[radeusgd]

As discussed in #13273 - we could try to simplify the Column.is_column (and related DB_Column.is_database_column) checks to rely on case of or even is_a.

However, in practice that always ended up causing issues, so to not block big PRs I just kept whatever was working.

Still it may be worth investigating, because in principle is_a should indeed work and the fact that it doesn't hints at a possible issue with how we are working with the multi-types.

To reproduce the issue, just apply:

diff --git a/distribution/lib/Standard/Table/0.0.0-dev/src/Column.enso b/distribution/lib/Standard/Table/0.0.0-dev/src/Column.enso
--- a/distribution/lib/Standard/Table/0.0.0-dev/src/Column.enso	(revision ab2b6ba2484c681395ca7a42d61c1238553ea381)
+++ b/distribution/lib/Standard/Table/0.0.0-dev/src/Column.enso	(date 1750252587742)
@@ -67,10 +67,7 @@
 
     ## PRIVATE
        Checks if the given object represents a Column type.
-    is_column object -> Boolean =
-        Panic.catch Type_Error handler=_->False <|
-            _ = object:Column
-            True
+    is_column object -> Boolean = object.is_a Column
 
     ## PRIVATE
        ADVANCED

or alternatively

diff --git a/distribution/lib/Standard/Table/0.0.0-dev/src/Column.enso b/distribution/lib/Standard/Table/0.0.0-dev/src/Column.enso
--- a/distribution/lib/Standard/Table/0.0.0-dev/src/Column.enso	(revision ab2b6ba2484c681395ca7a42d61c1238553ea381)
+++ b/distribution/lib/Standard/Table/0.0.0-dev/src/Column.enso	(date 1750252587742)
@@ -67,10 +67,9 @@
 
     ## PRIVATE
        Checks if the given object represents a Column type.
-    is_column object -> Boolean =
-        Panic.catch Type_Error handler=_->False <|
-            _ = object:Column
-            True
+    is_column object -> Boolean = case object of
+        _ : Column -> True
+        _ -> False
 
     ## PRIVATE
        ADVANCED

Either one seems to cause test failures (in Database backends) like:

[FAILED] [SQLite File] Numeric_Column: [2/5, 435ms]

    - [FAILED] a numeric column supports abs operation [28ms]
        Reason: An unexpected dataflow error (Invalid_Value_Type.Value a numeric Mixed DB_Column X) has been matched (at Table_Tests\src\Common_Table_Operations\Numeric_Column_Spec.enso:49:13-62).
        at <enso> Value_Type_Helpers.raise_unexpected_type(C:\NBO\enso\built-distribution\enso-engine-0.0.0-dev-windows-amd64\enso-0.0.0-dev\lib\Standard\Table\0.0.0-dev\src\Internal\Value_Type_Helpers.enso:305:5-21)

[radeusgd]

The point of interest is Value_Type_Helpers.find_argument_type. It needs to distinguish if a value is a column or 'scalar' value. Apparently with changed is_column implementation it sometimes fails to do so for DB_Column.

This is weird because a DB_Column should always have a (possibly hidden) & Column part. I suspect the & Column part gets completely removed under some circumstances.

My hypothesis is that it disappears when we dispatch a method that is defined on DB_Column and the compound multi-value loses the additional types once it is passed as the self argument. I'm not sure if this is the true reason though - that needs further investigation. (Possibly related PR: #12170)

Anyway, we should figure out why the & Column part seems to disappear sometimes. The conversion-based approach to Column.is_column is working, but it is not really solving the root cause. Once a DB_Column is instantiated as a 'subtype' of Column via the & Column intersection type it should rather stay that way (even if the type may become hidden). The type being removed may lead to many subtle issues like this in the future.