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

Option to use static extension with implicit casts #9847

Closed
xm75 opened this issue Aug 18, 2020 · 4 comments
Closed

Option to use static extension with implicit casts #9847

xm75 opened this issue Aug 18, 2020 · 4 comments
Milestone

Comments

@xm75
Copy link

xm75 commented Aug 18, 2020

Adding something like @:using could fix the current incompatibility between the static extensions and implicit casts.

This is related to: #5924

@RealyUniqueName
Copy link
Member

Please elaborate. Preferably with code samples.

@xm75
Copy link
Author

xm75 commented Aug 18, 2020

When used, this option would make the static extension and implicit casts work the same way as before #5924.

Something like this:

@:forward
abstract X(MyType) {

    @:from
    @:using
    static public function fromA(a:A) {
        return cast a;
    }
  
    @:to
    @:using
    public function toA():A {
      return cast this;
    }
}

Maybe there are better solutions, but it's pretty inconsistent that now this things can't be compatible.

@RealyUniqueName RealyUniqueName added this to the Design milestone Aug 18, 2020
@Simn
Copy link
Member

Simn commented Aug 18, 2020

That would be pretty awkward to implement because we usually distinguish expression-based unification from typed-based unification purely by context. With something like this we would have to try the expression-based approach and if we come across a casting field that isn't marked with @:using we would have to fall back. And that also raises more questions, like should the fallback attempt to find other casting fields which might have a @:using or should it go straight to type-based unification?

I wonder if we should instead simply always use expression-based unification for anything that is brought into context via @:using. But somebody has to think that through as well.

@Simn
Copy link
Member

Simn commented Feb 6, 2024

This would have to go through haxe-evolution.

@Simn Simn closed this as completed Feb 6, 2024
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

3 participants