> Yes I know it doesn't have it, it was a subtle way of asking if one day, > the compiler may have inferences capabilities. I know it's not really > possible until it continues loading code dynamically at runtime, but in > some scenarios (such as preload, or inherited/implemented class type > checking) it may be possible, I'm only hard guessing here >
Preloading can help a little bit, but still, the possible return types of all the calls have to be inferrable at compile-time in all the affected code paths. It seems pretty much unfeasible for me in most of the cases. Return types being added automatically really looks like inference > already, just a simple one, I guess. Indeed, internal method return types were "inferred" based on their implementation, but this was done manually, and we documented them in the so called stubs. It's also an extremely slow way of "inference", since the whole project took more than a year. ^^ > I'd love it. In all inheritance or > interface implementation scenarios, it seem possible, since the compiler > needs to load the implemented or inherited class code to be able to > compile the current class. > If return types were added implicitly, then you would get a diagnostic each time a function returns an incorrect value, so the error log messages could easily go out of control. Besides, you would also need a good IDE to be able to know the exact return type, which is a bit cumbersome if you only scroll through the code on web platforms like GitHub. Máté
