Stefan Glienke

I am sure that plenty of 3rd party tools will fall apart at first with 10.3 when they encounter a var or const at places they are not expecting them 😉

A few closures are not functional programming 🙂 Even less so if they are not pure. Yes, you can borrow a fraction of concepts from FP but you cannot do FP in a non FP language.

Useless in this case because then the implementation of the interface method would have to know one particular implementation of that interface already.

The issue is that it is ambiguous. Usually you store reference counted objects as interface reference, not as object reference. If you pass that variable into some method that triggers reference counting your object might be prematurely destroyed and you run into an error once you hit the Free call. Imo the compiler should help you here to avoid coding errors and warn about this inline declaration potentially being wrong (guessing either way might be wrong) when inferring the type.

The benefit of type inference is that you don't have to state the obvious. If you put the result of let's say GetCustomers into a variable it can explicitly type that variable from the type that GetCustomers returns, if that is a TList<TCustomer>, a TCustomerList or something else it usually does not matter. It also might make refactoring more stable because if you might change that function to return a more special or a more broad type then there is a high chance that the code will still compile and work.