Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

An EitherType constraint causes oddities when used as a map key #11401

Open
YellowAfterlife opened this issue Nov 21, 2023 · 2 comments
Open

Comments

@YellowAfterlife
Copy link
Contributor

Sample:

import haxe.extern.EitherType;

@:keep class Test {
	static function main() {
		var tc = new Impl<ETest>();
		trace(tc.labels[One]);
	}
}
abstract class Base<T:EitherType<EnumValue, String>> {
	public var labels:Map<T, String> = new Map();
	public function new() {}
}
class Impl<T:EnumValue> extends Base<T> {
	
}
enum ETest {
	One;
	Two;
}

So, two things:

  1. Perhaps this should not compile unless there"s a multitype that can accept both key types.
  2. On JS with -dce full, this results in compiler picking StringMap but culling its get() method, causing a runtime error.
@kLabz
Copy link
Contributor

kLabz commented Nov 21, 2023

EitherType is meant to be used to describe types when writing externs (hence the package name), but won"t provide good typing for actual code.

It is useful for interfacing with external code on dynamic platforms such as JavaScript or Python.
Otherwise, use of this type is discouraged.

@YellowAfterlife
Copy link
Contributor Author

YellowAfterlife commented Nov 21, 2023

That is true - I was a little too quick trying to retrofit existing code (which, for the most part, passes values to external JS) to also accept strings/arrays of strings (instead of Haxe enums) coming from external JS, and did not think about the implications until I got the code to run.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants