Dalija Prasnikar

You can use RegEdit to remove registry key HKEY_CURRENT_USER\Software\Embarcadero\BDS\21.0 Deleting (or renaming) that key will remove all custom settings. If possible it would be good to determine source of your problem. Do you have any IDE plugins installed in 10.3 or other 3rd party components - packages (including your own). Maybe imported settings are trying to load something incompatible. I just tried to import my settings from 10.3 again in 10.4 and everything works fine for me.

Err... that option does not exist any more. You have to use migration tool to preserve settings if you are reinstalling and updating and also for upgrading to new major version.

This might be a bug, then. I just found one similar to what you are describing IDE does not remember user color seting for source editor https://quality.embarcadero.com/browse/RSP-28754

There is new option in Options -> User Interface -> Theme Manager called Toggle style to match Windows Light and Dark mode. It is checked by default and that setting overrides any other custom settings. You need to uncheck that option before you can use custom theme settings. If you want to edit registry directly under Theme key, this new option is called ToggleTheme (DWORD) and its value should be set to 0

There is a bug. You cannot move active tab. You need to select some other tab first and then you can drag the tab you want. Cannot rearrange editor tabs, when it is selected https://quality.embarcadero.com/browse/RSP-28465

You already fixed the issue, but that issue is already fixed in Omni Thread, too. There is newer version in the making, not released yet, but it has fixes and packages for 10.4. Last commit was just 4 days ago. https://github.com/gabr42/OmniThreadLibrary When new Delphi release comes out and you find issues with some of the libraries you are using, it is good to recheck library for updates. Keep in mind that libraries cannot be publicly updated before official release and sometimes takes a few days to have those patches and fixes generally available.

It is simpler, but not faster. FWIW, I am using the same simple implementation because I don't need that extra speed. Smart pointer already brings in some performance drop and in places where I can live with that I can also live with unoptimized version of smart pointer. But if you really want to use smart pointers and you really need every last CPU cycle you can squeeze out of it, then Spring4D is the way to go.

You missed it... look for Options button in the bottom panel (on the left of Next, Cancel... ) I am not sure whether it shows in first or second screen... but it is there.

This one is rather important fix - it is fixed for both LSP and Classic Code Insight Code completion does not work inside anonymous methods https://quality.embarcadero.com/browse/RSP-23252

https://dalijap.blogspot.com/2020/03/unified-memory-management-coming-with.html Yes, 10.4 will have unified memory management on all platforms.

I have created GitHub repository with code examples from my book Delphi Memory Management for Classic and ARC Compilers. It is still work in progress (there is plenty of code) and currently, it contains examples from Part 1 and Part 5. The rest is coming... https://github.com/dalijap/code-delphi-mm

This is not official advice... I would try contacting sales, or support https://www.embarcadero.com/support or some of Embarcadero Product Managers like @Marco Cantu

It is important to note that anyone with active update subscription can participate in Beta https://community.idera.com/developer-tools/b/blog/posts/get-ready-for-the-10-4-beta-with-update-subscription

You are right about permission part. "Sorry, I can't say anything, because of RadStudio Beta NDA will kill me and eat my soul" is still valid for everything else.

I cannot say I had such encounters. In every place I tried to use them, main problem was killing code completion and navigation (or maintaining backward compatibility) I also used them (actually, type inference that comes along) in some places where my old library code was no longer compilable in Rio - mostly around changes in generic lists and Items.

There have been few bugs around inline variables, but for using inline variables in day to day code, probably the greatest problem was non functional code completion and code navigation. They would also break Error Insight, but that thing is all kinds of broken, so having one more way to break it is not critical. Besides, Error Insight itself is not critical feature. On the other hand, one permanent pitfall lies in inline variables combined with type inference and reference counted classes as explained in my blog post https://dalijap.blogspot.com/2019/03/inline-variables-type-inference-and.html

There is complete list of iOS devices at https://en.wikipedia.org/wiki/List_of_iOS_devices iPhone 5 and iPhone 5C are 32bit, while iPhone 5S is 64bit. Anything having 6 in name is 64bit, Just check whish OS version is the latest version particular device supports. iOS11 and newer only support 64bit devices. Official numbers can be found on https://developer.apple.com/support/app-store/ but they only show stats for devices released in last four years. As far as whether you need to support 32bit applications or not, that is hard to say... depends on your audience (kids can still play games on ancient iPads and don't care about how old that thing is). But most likely 32bit can be safely ignored.

There is nothing compiler can do here. Compiler does not have intrinsic knowledge how particular class implements reference counting and therefore cannot emit warnings in proper places because it does not know whether particular piece of code is correct or not.

Full ARC compiler on all platforms and getting rid of TComponent ownership model would be the only proper solution. But that would definitely not make everyone happy. Maybe additional "interfaces" as abstraction that is not tied with memory management could solve most of the issues, but I never given that too much thought in terms of finding potential gotchas and additional levels of complexity such feature might add.

No,, but learning takes time. I am not talking here about lazy people that don't want to learn, I am talking about efficiency of learning a language that has additional levels of complexity comparing to learning language that doesn't and where both languages are generally suitable for solving some problem. I know that knowledge accumulates over time, so you will not have to relearn things you know the next time around, but such things do have overall impact on productivity.

Yes, it is an issue. Even if you ignore "just don't do it" part which you first have to know exists and then have to learn how to do properly in Delphi (not so easy as in Java, C# or other languages where you can use interfaces easily), main problem is that you cannot just have some IFoo interface and implement it on every class you like and use it equally. As long as all implementing classes handle ARC the same way, it is fine, but try having IFoo on TInterfacedObject descendant and TComponent descendant and you are basically screwed (or at least seriously limited in what you can do with such classes).

Which is exactly one of the issues mentioned in article. Interface should be an abstraction that is always handled the same way, but implementation details of the particular class will leak and in some cases you will need to know how implementing class handles memory management. And then whole abstraction castle will just collapse.

Yes, interfaces in Delphi are troublesome. From perspective of being tool for achieving abstractions they are commonly more trouble then they are worth. Chad explains some issues well. If they are used as COM interoperability, then there is nothing wrong with the because that was exactly their original purpose. If you are looking on them as tool that can give you automatic memory management they are great, because you can more easily solve some otherwise complex problems that would require complex solutions. However, their use in such cases is limited and you cannot use them for such purpose everywhere. For instance you cannot add ARC to visual frameworks that are build on top of TComponent ownership model and automatically handle lifetime of your visual controls. Main problem with interfaces is not that they are badly done per-se, but that they add duality to Delphi memory management and as such additional complexity and care is needed when you are using them. That is one of the reasons why I liked mobile ARC compiler. It showed that without that duality interfaces and objects can live happily ever after and that you don't have to look around your shoulder every time you use interfaces, expecting that they will kick you in behind. Of course, full ARC brought other issues, but those were related to using existing frameworks that were not written with ARC in mind, so we got that dreadful DisposeOf... No matter how you look at it, Delphi memory management is complex, sometimes too much... it is not question of being able to learn about things, but about how easy and how fast can you write your code, focusing on task at hand without needing to fiddle with all nuisances of handling your objects lifetime.

No caveats for above code. You can freely Free object instance from different thread than one where it is created. Problem would arise if you would have object instance that is being simultaneously accessed by multiple threads.

I assume you meant "FMX will improve faster without ARC. " But, no, FMX improvements (as in framework improvements) are in no way related to memory management model. The only difference between FMX and VCL code related to memory management is that FMX calls DisposeOf to release FMX components and VCL calls Free. Bottom line, FMX will just run faster on mobile platforms without ARC, but that is it. Other improvements will come (or not) unrelated to the memory management mode change.