Stefan Glienke

Record creation does not take time because they are value types and live on the stack. If the ctor, dtor and assignment operators are called directly by the compiler and can possibly even be inlined this will have very little overhead which is negectable.

Bad connection in the outback? 😄

Inline variable declaration and type inference has nothing to do with FP at all.

I think the current layout it wasting very much vertical space which makes it necessary to scroll even after a few one liner comments. This is caused by - the information about the poster on the left side that takes more space than necessary (even if his name will be moved from the post header) - the footer line which just holds the quote and like buttons Example: Take a look at the first 3 comments - they are one liners but take the entire height of a 1680x1050 screen.

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.