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

cannot use @:const type parameter with haxe 4 preview 5 #7574

Closed
romamik opened this issue Oct 25, 2018 · 2 comments · Fixed by #11376
Closed

cannot use @:const type parameter with haxe 4 preview 5 #7574

romamik opened this issue Oct 25, 2018 · 2 comments · Fixed by #11376
Milestone

Comments

@romamik
Copy link
Contributor

romamik commented Oct 25, 2018

With 4.0.0-preview.5 this example does not compile with error: Only Const type parameters can be used as value. With haxe 3.4.4 it compiles fine.

@:generic
class Foo<@:const FOO:Dynamic> {
	var foo = cast(FOO, String);

	public function new() {}

	public function test() {
		trace(foo);
	}
}

class Test {
	static function main() {
		var foo = new Foo<"Y">();
		foo.test();
	}
}
@Simn
Copy link
Member

Simn commented Nov 13, 2018

I didn't intend to break it, but now that it's broken I wonder if we should remove this feature altogether. I'm fine with macros processing constant type parameters, but supporting this in the typer as some sort of silly dependent type seems like it's not worth the complications.

Is this actually useful for anything in the real world?

@romamik
Copy link
Contributor Author

romamik commented Nov 13, 2018

I used this like this. I have some gui-system, and have two classes VBox and HBox, that differ only by the axis they use. This feature allowed me to make one class with type parameter. Together with analyzer-optimize this approach gives very clean output. Here is very basic example: http://try-haxe.mrcdk.com/#D725e
Note code in LinearBox.applyLayout() function. It's axis-agnostic and I don't know better approach to do this. Currently I'm doing this with calling inline function defined in base class but this does not look that good.

@Simn Simn added this to the Design milestone Dec 12, 2018
Simn added a commit that referenced this issue Nov 15, 2023
@Simn Simn closed this as completed in 128261a Nov 15, 2023
0b1kn00b pushed a commit to 0b1kn00b/haxe that referenced this issue Jan 25, 2024
* change return of build_instance to record

* also rename

* also seperate

* also bring back typedef deprecation check

* alsp keep special cases in the right place

* mess around

* avoid some work if we need no params anyway

* make @:generic inference work again

* remove Generic_Exception

* push expected type before loading instance

closes HaxeFoundation#3864

* expand generic types on field call candidate when expanding generic function

closes HaxeFoundation#5482

* build generic parents as well

closes HaxeFoundation#6761

* inherit `@:autoBuild` to generic instance

closes HaxeFoundation#5536

* also inherit @:keepSub while we're at it

closes HaxeFoundation#6500

* deal with KExpr in generic classes properly

closes HaxeFoundation#7574

* don't inherit cf_expr_unoptimized to generic instances

closes HaxeFoundation#9358

* reroute FClosure in map_expr_type

closes HaxeFoundation#9395

* inherit cl_using to generic instances

closes HaxeFoundation#10528

* set inherited flags on generic instance fields at the right time

closes HaxeFoundation#11010

* I really don't care

* wild guess

* avoid the follow change
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

Successfully merging a pull request may close this issue.

2 participants