Stefan Glienke

It will only break it as long as DelphiAST does not support the new syntax 🙂

Using that feature in code that also needs to compile in versions before 10.3 makes no sense - however once we migrate to a version that has this feature I will use it in company source code with great joy.

It has the overhead of being an interface, causing heap allocation and doing a call every time you access it. In 1.3 there will be some optimizations to reduce that. The only solution that will not cause all this is the one I described previously.

The difference is the implementation, why put something into TObject which is then turned off for everything unless I need it. This is already the case for TMonitor which is kinda arguable. Putting the RefCount field into every single object instance only wastes memory. So if you are for explicit opt-in it not being part of TObject itself is way better. So if we get records that are not running through InitRecord, CopyRecord and FinalizeRecord but directly call their constructor/destructor/copy operator you get rid of all that overhead and don't need records wrapping interfaces (no heapallocation needed as well). If we then possibly also get a way to do operator lifting/hoisting we get rid of the current need to write .Value when accessing the stored value (which is why I wrote IShared<T> where you don't have to).

If you haven't watched this before it might make it a bit clearer what it means to have modern compiler architecture and what benefits you get from it (like not having to implement everything twice for compiling itself and for tooling):

Because that would only make initializing with const values possible and not like now initializing with function results. So I guess their reasoning was to not extend existing variable declaration in a very limited way but go the full distance.

It would be wrong in the same way as most of the time it is wrong to mix object and interface references because as soon as interface reference is triggering ARC your instance might be prematurely destroyed.

Afaik it does not. However that is why there is Shared<T> and IShared<T> in Spring. First one is for easy creation because of implicit operator, second is for easy access as its an anonymous method type and the invoke takes almost zero time. With the type inference in 10.3 however the second one also has pretty easy creation as Primoz showed earlier.

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.