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

static extension with @:generic type #10528

Closed
Antriel opened this issue Dec 15, 2021 · 1 comment · Fixed by #11376
Closed

static extension with @:generic type #10528

Antriel opened this issue Dec 15, 2021 · 1 comment · Fixed by #11376
Milestone

Comments

@Antriel
Copy link
Contributor

Antriel commented Dec 15, 2021

All works if Data is not made @:generic. Two issues:

  • Is Data<String> not supposed to work with function foo<T>(d:Data<T>), if it's generic?
  • The difference in behavior between explicit using Extension; vs default @:using(Extension).
using Test.ExtensionA;
class Test {
    static function main() {
        var p = new Data("foo");
        ExtensionA.getDataA_A(p); // Error. `Data_String should be Data<Unknown<0>>` why?
        ExtensionA.getDataA_B(p); // Works.
        ExtensionB.getDataB_A(p); // Error. Same behavior for explicit or metadata `using`.
        ExtensionB.getDataB_B(p); // Works.
        p.getDataA_A(); // Error. Basically the same behavior as with direct calls.
        p.getDataA_B(); // Works.
        p.getDataB_A(); // Error.
        p.getDataB_B(); // Error. Just because it's a default extension via `@:using`?
    }
}

@:using(Test.ExtensionB)
@:generic class Data<T> {
    public var data:T;
    public function new(data) this.data = data;
}

class ExtensionA {
    @:generic public static function getDataA_A<T>(d:Data<T>) return d.data;
    @:generic public static function getDataA_B<T, D:{data:T}>(d:D) return d.data;
}

class ExtensionB {
    @:generic public static function getDataB_A<T>(d:Data<T>) return d.data;
    @:generic public static function getDataB_B<T, D:{data:T}>(d:D) return d.data;
}
@Simn
Copy link
Member

Simn commented Jan 20, 2022

This issue is a convoluted mess.

The difference between normal/default using can be seen here:

using Main.ExtensionA;

class Main {
	static function main() {
		var p = new Data("foo");
		p.normalUsing();
		p.defaultUsing(); // Data_String has no field defaultUsing
	}
}

@:using(Main.ExtensionB)
@:generic
class Data<T> {
	public var data:T;

	public function new(data)
		this.data = data;
}

class ExtensionA {
	public static function normalUsing<D>(d:D) {
		return null;
	}
}

class ExtensionB {
	public static function defaultUsing<D>(d:D) {
		return null;
	}
}

I expected this to work after d1a2bd1, but it doesn't.

@Simn Simn added this to the Later milestone Mar 24, 2023
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