Eric Lippert

Eric Lippert is a programming language designer; prior work includes the C#, Hack, JavaScript and Bean Machine compilers. Blog at

[Eric Lippert @ericlippert]

I'm heading over to https://t.co/Y398hVuieQ, hope to see you there!

[Eric Lippert @ericlippert]

@codelumpn @panopticoncntrl That said, the design team is very aware that overload resolution is too complex for users to understand. Most treat it as a black box that does the right thing most of the time and is puzzling when it does not. Which is perhaps not ideal, but there won't be an ideal design.

[Eric Lippert @ericlippert]

@codelumpn @panopticoncntrl Design is a failure when it doesn't meet the needs of users, not when it complicates the job for implementers. I am proud of the work we did in both design and implementation here.

[Eric Lippert @ericlippert]

@AndrewStellman Please do!

[Eric Lippert @ericlippert]

@AndrewStellman That's why organizations such as the Jet Propulsion Lab run static analysis tools on all their code and fix all the bugs reported *even if the report is a false positive*.

[Eric Lippert @ericlippert]

@AndrewStellman Moreover: though the *compiler* doesn't care about readability, static analysis tools do. If your code is correct but so unreadable that a static analysis heuristic is fooled into reporting a false positive, then humans will also likely be unable to understand it.

[Eric Lippert @ericlippert]

@codelumpn @panopticoncntrl I also left a debug-only "Dump" method to make the report human-readable. Debugging mistakes in overload resolution and its error reporting got MUCH easier when I could just ask the debugger for a human-readable summary of the analysis. I highly recommend that technique!

[Eric Lippert @ericlippert]

@codelumpn @panopticoncntrl If you look at
https://t.co/UhpakgLcjs

you can see all the possible ways a method can fail to be best, and in

https://t.co/ebg9fC2b8B

method ReportDiagnostics we have the heuristic for turning an analysis into an error message. I left LOTS of comments!

[Eric Lippert @ericlippert]

@codelumpn @panopticoncntrl The way I implemented this was: for all the attempts at inference and all the candidates for overload resolution involving lambdas, we track the errors that *would* have been reported had the types of the parameters been known, and then see if there's a common error.

[Eric Lippert @ericlippert]

@codelumpn @panopticoncntrl My point here is that we do NOT want to say "inference failed" or "overload resolution failed", even though those things are true, because they're not *actionable*. What we want to do is point the user at the thing that needs to change: you made a typo in the lambda body.