`match` enum with Int64 param

1

I expected to be able to match() enum value with Int64 parameter by using Int literal (because Int64 has @from Int) but it is not the case: Try Haxe!

Is this the way things supposed to be or am I missing something?

Also, you can’t match( FOO( Int64.ofInt(42) ) ), but that’s would be a bit cumbersome anyways even if possible.

3

To clarify the root of the problem is that there is no such thing like a Int64 constant, and .match() will only accept constants, not an expression that would return a value or some implicit conversion.

I thing the reason behind is that .match works at compile time, but not sure.

But you are right that numeric literals should be valid in place of any bitness, or a Int64 kind of literal should be intriduced.

4

Since match implementation differs between native and via different libraries it is probably better to stick with the more established switch method when possible. Perhaps there is a cleaner approach but this works.

enum Foo {
  FOO( v : haxe.Int64 );
  BAR;
}

class Test {
  static function main() {
    var nv1 = FOO(42);
    var nv2 = FOO(44);
    
    checker(nv1);
    checker(nv2);
  }
}
function checker( v ){
  var n64 = haxe.Int64.toInt(42);
  var found: Bool = switch( v ){
			case FOO(val):
                          trace(' FOO found');
                          switch( v ){
      	                       case val == n64 => true:
      		                   trace('val is $n64');
      		                   trace( v );	
      		                   true;
                               case _:
      		                   trace('FOO does not contain $n64');
         	                   false;
                          }
               case BAR:
      	             false;
    }
    trace( 'found $found' );
}

sorry not sure how to get formatting correct.
Generally it is much easier to deal with more complex compile time type matching using the flexibility of switch statements, just it may require more checking manual and some experimentation. Match is a more recent addition and likely more suited to string regex, especially as it makes use of native or a lib implementations that will not be as compile time flexible, ie not as closely aligned with haxe compilers type manipulation.