Wrong single/double/extended overload selection when using literal integer numbers
Original Reporter info from Mantis: Gorelkin
-
Reporter name: Sergei Gorelkin
Original Reporter info from Mantis: Gorelkin
- Reporter name: Sergei Gorelkin
Description:
See the attached test case.
With both current trunk and 2.6.2, all three calls resolve to the (single,single) overloaded procedure, despite presence of explicitly-typed first parameter.
If integer constants (0) are replaced by floating-point ones (0.0), then the test works as expected.
Probably the conversions that can be done at compile time should have less weight in overload selection than run-time conversions, regardless of their complexity.
Mantis conversion info:
- Mantis ID: 25478
- Version: 2.7.1