Type Constraints of multiple types


Sorry if this is was answered before, but I’m having difficulty finding an answer in the docs.

I have a function which accepts a type parameter, and I would like to have the compiler check if this parameter is one of a limited number of types (String, Int, Float, Bool). A simple example of such function:

public static function get<T>(param:T):T {
	return param;

Now, the docs mention I can set multiple constraints on <T> and have something like <T:(Iterable<String>, Measurable)> but that would mean a class must implement both types to comply. Is there a way for specifying multiple, unrelated, acceptable types? So I can have get("Hello") or get(12) working, but not get([1,2,3]) ?


What kind of function are you trying to do?
Because you can only do on T what’s possible on all T. Like you can’t do T*2 for string or bool.

It does nothing with T itself, so it shouldn’t be a problem.
Specifically, the use-case I have is a function that tries to get a value from a map of multiple types (all basic types) and defaults to return a value of type T (depending on the call) if nothing is found.

If you don’t do anything with the type parameter, including using any value of type T, I’m not sure why you need if in the first place?

Anyway as far as I know haxe doesn’t have anything to do that.

You might be looking for an enum based variant type? Like haxeui-core/Variant.hx at cd8b68a3d876e756f16640000f67f78b62d74cb4 · haxeui/haxeui-core · GitHub

leshido, “I’m not comfy-cozy with that use case of yours,” and I would frankly encourage you to step back from your present course and to consider a different approach.

For one thing, if you try to make a single class/method “too smart,” especially if it can somehow accept both a scalar and a vector, then it becomes very easy for the end-user programmer to write incorrect code and then not to discover the error of his ways until run-time. (Which is precisely why I have so much trouble with languages like JavaScript.) It’s also hard to turn this into a compiled representation that is efficient: you’re forcing it to make extra decisions millions of times per second. Writing the class itself is hard – writing it correctly is much harder.

Thus, I would look for a design that starts with abstract classes (and interfaces), and then moves to one or more concrete implementations that are more specific. I’d specifically suggest building them so that as many programmer mistakes as possible can be reliably trapped at compile time, because that’s where “strong typing” translates into serious code confidence improvements and time-equals-money savings. Try to work that to your advantage.

Hey @sundialservices, thanks for your input :slight_smile:

Not entirely sure what it is you’re not feeling “comfy-cozy” with, as the strong-typing nature of Haxe is precisely what I was hoping to leverage in order to catch would-be errors in the compiler.

Anyway, in the end I opted to use Macros to help with this. I’m posting a slim version of this in this Gist, in case anyone is curious.