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

Abstract operator error #4914

Closed
ncannasse opened this issue Mar 8, 2016 · 5 comments
Closed

Abstract operator error #4914

ncannasse opened this issue Mar 8, 2016 · 5 comments
Milestone

Comments

@ncannasse
Copy link
Member

This gives some strange error:

// -lib heaps
class Main {
    static function main() { 
        var s : hxd.UString;
        var life = 8;
        s = (life > 9 ? '' : '0' ) + life;
    }
}

It actually depends on the conditional check being there.

@Simn
Copy link
Member

Simn commented Mar 8, 2016

  1. Due to WithType propagation on abstract operations #2786 UString is pushed onto the operands as a with_type.
  2. The TIf typing does cast_or_unify of the then/else expressions against the with_type. This succeeds because UString has from String.
  3. You end up with UString + Int which the compiler doesn't like.

@Simn Simn modified the milestone: 3.4 Mar 16, 2016
@ncannasse
Copy link
Member Author

Looking at this, I understand how it works but I'm still not very happy with the way the compiler react. However doing this properly is quite hard since it would involve resuming from the error and trying again to type this time without the with_type constraint, which I'm sure you will not like :)

@Simn
Copy link
Member

Simn commented Dec 15, 2016

The general problem I see is that "trying again" and our type inference don't work together very well in general. There are too many monomorphs floating around which can be bound to something before the compiler decides to "try again".

@Simn Simn modified the milestones: 3.4, 4.0 Jan 9, 2017
@Simn Simn modified the milestones: Release 4.0, Design Apr 17, 2018
@Simn
Copy link
Member

Simn commented May 30, 2018

I still don't know what to do with this. I feel like #2786 was a mistake and now we run into situations like this.

@Simn
Copy link
Member

Simn commented Jul 2, 2019

This doesn't reproduce anymore. I don't know why, but let's quickly close it before it comes back.

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