Stefan Glienke

Wow they are still (happened on the old forums as well) leaking email addresses in the usernames as they seem to be generated from the email used on the old community page ...

I am sure using the type keyword after the equals sign was not part of the original pascal syntax and is only there to let the compiler produce a new typeinfo instead of it just being an alias that still points to the exact same type.

Agreed, type redeclaration is really not very helpful in many situations. - you still have implicit type compatibility no matter what - but helpers stop working

And after that you show why the "right" way is bad... An URL consists of different parts which combined give a string, yes but should be represented as the different parts, hence the record. Especially since there are cases where such a type cannot just be represented as string or number but consists of different data of different types. Yes there might be a string representation but it should not be passed as that through your API.

It will not get them more customers just because it's 64bit and runs out of memory later because all the instabilities and the compiler getting into a bad state because of compile errors or what not crashing the IDE will still be there as will the poor code tooling. Going the easy/cheap way every time is what puts Delphi and the IDE into the current situation of constantly having to react to external factors and tinker around edges. Sometimes I really have a hard time believing that or you just avoid certain features or have subconsciously developed a certain habit to do things differently. Or you just use it to prepare demos.

The benefit of the TUrl type opposed to differently named overloads is also that you declare a domain type and make the API cleaner than just (string, string, string) regardless the naming of the parameters

Well you have a different definition then than Intel in paragraph 8.1.1 it seems. So unaligned data can be as well part of a struct/record which fits into a cache line and thus is guaranteed to be atomic.

isAtomic := not IsCrossingCacheLine(unalignedData);

Get into the beta - I guess being a maintainer of one of the most noticeable IDE plugins might help even if you are not on subscription personally. @Marco Cantu @David Millington might be helpful with that.

Yeah, then the IDE can more excessively waste memory left and right until your RAM is used up instead of crash early, brilliant idea... Throwing more memory at an application that does not know how to properly manage memory is not the solution. Oh, please, no excuses about the compiler leaking memory because of LLVM, if you know that then don't load it into the IDE process. Ah, that has to be done to use it for IDE tooling, like code completion and all kinds of source related things. Now you see why other languages and IDEs go the way of separating this and using a language service to provide such information

That fact that you have to mark overloads to a virtual method as reintroduce always bothers me but I never cba to actually report it.

And how exactly can we call Add on that "New" record if ?

Well, New.Of could return a record that has implicit operator overload to be assignable to the s1 variable which then implicitly goes out of scope at the end of the routine.

It is very unfortunate that you used merge to get the latest master changes into your fork rather than rebasing. That makes looking at your changes very difficult (I had to look back through the commits until I found yours that were not integrated into master via PR). Also having all changes in one branch will result in some huge PR whereas putting each different change into it's own branch and submitting PRs for that would be easier to review. I don't know about Roman but I would not accept a PR with a ton of different fixes where I cannot separate them from each other and validate them individually. I just bring this up because I want those bugfixes incorporated back into the main project.

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.