This forum is deprecated.
On behalf of Embarcadero, the RAD Studio product management team is in charge of continuously updating the product development roadmap for Delphi, C++Builder, and RAD Studio. As you can see in our official roadmap blog post, we have just released a new version of the roadmap, covering the key features that we’ve planned for the next 12 months. Along with the official roadmap slides, we wanted to offer more details, information and insight with this additional blog post. You may find it useful to open the slides for reference while reading the expanded information we provide here.
In our roadmap, you can find the key features that we’ve planned for calendar year 2019/2020. Before we get to the details of our updated roadmap, we wanted to recap what we’ve delivered so far. Towards the end of last year, we released 10.3 Rio. The 10.3 Rio release was very well received by our customers and included C++ 17 for Win32
support which addressed a very long standing customer request, new Delphi language features
such as the new inline variable declaration syntax and FireMonkey z-order and native controls support on Android (with the ability to target API level 26, a Google Play Store requirement). Also included were key
Windows 10, VCL, and HighDPI improvements
, extensive IDE UI modernization
with new themes to improve the first user experience and longtime IDE use, RAD Server enhancements and quality and performance improvements
throughout all of the product areas and runtime libraries.
We followed up on the 10.3 release with 10.3.1 in February of 2019 which introduced expanded support for iOS 12 and iPhone X series devices
, RAD Server Console UI redesign with the migration to the Ext JS framework
and improved FireDAC support for Firebird 3.0.4 and Firebird embedded
. Also added in 10.3.1 were new VCL and FMX multi-device styles
and IDE productivity components, Navigator and Bookmarks, both available via the GetIt Package Manager in the IDE. The 10.3.1 release also included fixes to over 150 customer reported issues.
Currently in beta is our 10.3.2 release with features such as macOS 64-bit support for Delphi (including InterBase), Win 64 for C++17, RAD Server wizards, RTL performance enhancements and significant quality improvements throughout, available for testing. The 10.3.2 beta is an NDA beta, requiring participants to sign our non-disclosure agreement before being able to participate in the beta. If you’re current on Subscription and have not received an invite to join the beta, please contact your Embarcadero sales representative.
For the GetIt Package Manager, we plan to have some exciting announcements in the coming months around new plugins and add-ons from Embarcadero and our partners.
For 10.4, we are planning significant work around IDE tooling with Delphi support for the Language Server Protocol (we added initial support to C++Builder in 10.3, which we’re enhancing for 10.3.2) , VCL High DPI Styles support, Android 64-bit for Delphi, RAD Server tooling, expanded C++ libraries support, significant quality enhancements and more. See below and here for more details.
We wanted to take this opportunity to share with you more details on several key focus areas outlined in our updated roadmap.
Sarina focuses on FireMonkey, the component libraries’ UX and styles, the installation experience and demos and documentation
FireMonkey continues to be one of my focus areas as it has been since I joined the company in 2011. I love what developers can build with the framework.
As of August 2019, Google will require that all Google Play Store applications are 64-bit enabled. Android 64-bit support is actively in the works for Delphi as we speak. In time for this new Google requirement, we plan to kick off our 10.4 beta this summer with support for building Delphi Android 64-bit applications. While the usual beta restrictions do not allow for building and deploying production apps, we intend to include a special beta EULA provision that allows 10.4 beta testers to deploy (production) Android apps to the Google Play Store. We followed the same approach for 10.3 and Google’s API level 26 requirement last summer and that process worked well for our customers. InterBase support for Android 64-bit is also in the works.
Last year, Apple announced that it was deprecating support of OpenGL in favor of Metal 2, Apple's new GPU library. We are planning to support Metal 2 in the 10.4 release. macOS 64-bit support for Delphi will also provide the foundation for the iOS 11, iOS 12 and iOS 13 Simulator (once released) which we plan to support in a 10.4 point release.
Last year, Google deprecated Google Cloud Messaging, also known as GCM. We have built-in support in FireMonkey for GCM. Google has announced that the APIs are deprecated and will be removed as soon as May 29th, 2019.
In order to use push notification support in your FireMonkey Android applications going forward, you will need to use Google’s Firebase. We plan to soon release a patch and detailed instructions for RAD Studio 10.3.1 customers on how to add Firebase push notification support to their FireMonkey Android applications.
We intend to simplify this support in the 10.3.2 release (also adding support for Android Firebase push notifications in RAD Server) and provide fully integrated support for Firebase and additional related services in 10.4. One of the areas that we plan to revisit for 10.4 is our built-in advertising support to determine what it will take to support Admob on both Android and iOS, which is something we’ve gotten customer requests for.
Templates and Styles
Last year, we released a number of FireMonkey UI Templates that make it easy to get started building your own multi-platform applications. Those templates, available via GetIt, have been extremely popular and we’re actively working on additional templates, including some material design themed ones. If you have additional ideas for GUI templates you’d like to see, please reach out to me.
The new FMX and VCL styles that we added to GetIt with the 10.3.1 release have also been very popular. Applying a custom theme is one of the fastest ways to overhaul the look and feel of your application. You can download the templates and styles through the GetIt Package Manager in the IDE.
Related to enhancing the first user experience is also our work on a unified online and offline installer using our GetIt technology, designed to provide you with the same swift, efficient installer when you are not connected online. This will not only help with the initial installation, but also provide a smoother process for installing point releases since today we require customers to use the same installation mechanism for point releases as the initial install. By unifying the installation technology, customers using the offline installer will also be able to install additional platforms from the IDE, something that currently is only possible when choosing the GetIt online installer.
Marco focuses on the Delphi language and RTL, the VCL library and Windows integration, all things database and Web oriented, including RAD Server
One of my focus areas is the Delphi language and the low-level runtime library and platform integration. As Sarina just mentioned and as covered by our roadmap, our focus in the coming months is to deliver new native Delphi compilers for macOS 64-bit and for Android 64-bit. This will add 3 additional Delphi compilers to the existing ones, bringing the total to 11 (2 each for Windows, macOS, iOS, Android, iOS simulator and one for Linux). In the future we’ll deprecate those that become irrelevant, but for now, we are just adding a few more.
Bringing our compilers to new platforms is a significant effort, but that’s not the only effort we are going to undertake. We are also working to unify the memory model along all platforms by disabling the Automatic Reference Counted (ARC) model for objects on the mobile platforms, offering a single mechanism for all compilers and all target operating systems. We started making this change in 10.3 (for the Linux platform), and it was very well received by our customers. Continuing down this path will help us deliver on the promise of single source multi-platform (and doing it better than other competing solutions).
Nonetheless, we still plan on continuing work on the language itself, starting with managed records -- a feature we started working on for 10.3 but decided to delay as it wasn’t stable enough and caused issues in the compatibility with existing code. We take backwards compatibility very seriously, and are working on an architecture that will provide smoother migration of your existing code while delivering a very powerful additional language feature. Managed records are also the foundation of nullable types and additional memory management models, which are next in the list of features planned for the language.
As a side focus for the language and the compiler, we have significant plans to improve our IDE code tooling (Code Insight and related features) as explained later by David.
Along with the work on the compiler, we are focused on bringing the same RTL library to all of the new platforms we are embracing, with full integration for platform APIs and low level mechanism like exceptions handling, memory management, threading. While we don’t plan significant extensions to the RTL, we plan to work in two main directions. The first is performance, an area where there is always room for improvement and many customers are asking for. Delphi native applications provide a performance advantage and leaner memory consumption than other solutions, something that remains true if the RTL is up to the right level.
The second is overall quality and stability, critical for a library but even more for a fundamental library element like the RTL. There are specific areas like LiveBindings that need to be reconsidered for performance, and others like the Parallel Library that need a good focus in terms of quality and feature completion. Also, the HTTP client library needs continuous refinement for the different platforms, and so many other RTL subsystems.
Over the recent years, RAD Studio has not only focused on multi-device application development with FireMonkey, but we’ve also put a strong emphasis on VCL and the Windows platform, Windows 10 in particular. The library now has a number of specific controls for modern Windows 10 UI, offers deep integration with the WinRT APIs (including specific components for Bluetooth LE, Notifications, and Windows Store), and includes many new features focused on supporting High DPI and 4K monitors, including new controls and features introduced in 10.3. Additionally, the IDE offers integrated support for creating Windows 10 UWP apps using the Windows Desktop Bridge (aka Centennial Bridge). As part of the project options you can provide all of the configuration settings to generate an APPX for ad-hoc or Windows Store deployment.
We plan to continue in the same direction.
We want to improve the current VCL Styles architecture with full support for HiDPI and 4K monitors for styled applications, and also allow for mixing styled and non-styled forms and controls (also for better integration with all third party controls). Ultimately, the IDE, which is primarily a VCL application, will also benefit from this support.
Another area we are focused on is extending our support for Desktop Bridge and Microsoft’s new deployment model by embracing the MSIX installation format that is becoming the foundation for the Windows Store and enterprise software distribution.
Additionally, we are planning some research on XAML islands and related Windows 10 technologies that are making it possible to mix traditional GDI and User controls (the VCL is based on) with WinRT native controls like browsers, maps, and XAML surfaces, along with other drawing surfaces. This is an area Microsoft is still developing and we plan on adopting once it has become more complete and mainstream (in terms of versions of Windows that are supporting it).
David focuses on the C++ language, the debugger, and IDE and user experience
In November 2018, we released an upgraded version of our Clang-enhanced Win32 toolchain support C++17. In the next release, 10.3.2, we will also support this toolchain for Win64. This means that all of Windows will be using the new toolchain with C++17 support, updated standard library, improved RTL, and more. Notably this updated toolchain has better compatibility with the C++ standard, and also provides a better upgrade path from the classic compiler. Windows is the most important platform for our C++ customers, and providing the same toolchain and C++17 support for both Win32 and Win64 will address our top platform requests.
An overall focus for C++ both last year and this year is to radically improve it. We aim to make C++Builder lead in all areas. The toolchain upgrade to a recent version of Clang and supporting C++17 was a key effort here and is the foundation for significant future work.
This year, the largest focus will be on tooling support in the IDE. This includes code completion, error insight, refactorings, and more. These are areas that are key for productivity in the IDE, and where we acknowledge the need for work to match or even pass other code editors. In 10.3, we introduced code completion for C++ (for Clang Win32) using cquery: this runs the code completion engine asynchronously, allowing you to keep typing while it works, and out of process, meaning without using memory space inside the IDE itself. We've had a lot of customers use our cquery support, and provide valuable input on specific quality improvements they'd like to see in the next iteration of the feature. 10.3.2 significantly revises it, and will provide fast and high quality code completion, parameter completion, error insight, and more. If you join the 10.3.2 beta, you will be able to get an early look at all of the enhancements as they’re made available throughout the beta cycle.
As you will see in our roadmap, we also plan to integrate Visual Assist into C++Builder. Visual Assist is (and will remain) a plugin for Visual Studio, but the core functionality, such as refactorings and navigation, will be integrated into C++Builder as well. Visual Assist is a world leader in C++ tooling, providing better and more flexible tooling than is available in Visual C++, CLion, Resharper C++, or other products. Its integration will move C++Builder to the forefront of C++ developer tools.
Over the next year, we are also focusing heavily on support for widely used C++ libraries, as well as quality improvements. Today in GetIt, you can already install key C++ libraries such as Eigen, Google Test, and Boost, as well as half a dozen other useful libraries, all of which are listed in the Libraries category. New libraries will also be available in GetIt. We also aim that quality issues you may have encountered in older version are removed in each and every release, meaning there is significant value in using the latest version of C++Builder at any time.
We also plan on extending the CMake support we introduced last year to be integrated into the IDE.
Finally, to match Delphi removing ARC from all platforms, C++ will also match this. For C++ developers this is a great move, removing the mix of memory models and allowing you to use canonical C++ memory management patterns, such as smart pointers.
We have been having a lot of great discussions with our C++ customers, and Windows support and enhanced tooling and overall quality were the most requested focus areas.
We're addressing this in 10.3.2 with Windows 64-bit support for C++17. Code tooling and overall quality for C++ are a big focus for 10.4 and beyond. We're excited about all of the enhancements we have planned in these areas.
One roadmap change you may notice for C++ specifically is that we removed macOS 64-bit and Android 64-bit platform support for this year. This does not mean that we will not add support for these platforms for C++ in the future (and we will support these platforms for Delphi this year). While retaining support for existing platforms by providing 64-bit support for macOS and Android for C++Builder are still under consideration for a future release, we continue to seek your feedback about your needs as we evolve the roadmap. We welcome your input on your platform use and these plans, and learning more about your specific macOS and Android requirements.
Building on the Clang upgrade for C++ allows us to use a modern version of LLDB. We plan to integrate Delphi language support into LLDB, and migrate to using it for key platforms, starting with mobile and macOS. LLDB is a very full-featured debugger and this will give you a high quality and featureful debugging experience matching Windows on all platforms.
In RAD Studio 10.3, we introduced a new look and feel in the IDE. Over the coming releases, we are improving this, addressing quality, and adding some great new features. In RAD Studio 10.3.2, our focus is on UX quality. You will see many issues in the IDE resolved.
In subsequent releases, we will be focusing on new features in the IDE. The most significant one comes in early 2020, when we plan to have high DPI support in the IDE. This means the IDE will scale correctly, and render crisply, on very high resolution monitors, such as 4K screens, or when Windows is using a non-100% scaling setting.
This work builds on the high DPI support in the VCL we introduced in 10.3, including high DPI image lists, and high DPI VCL style support in 10.4 as mentioned by Marco earlier. RAD Studio is built using RAD Studio, and so these features as they are introduced are also made use of in the IDE itself.
In the C++ section above, I mentioned how we are using cquery for C++ code completion, and how that technology will be significantly improved in 10.3.2. Cquery is a Language Server Protocol (LSP) language server. LSP is a JSON-based protocol for communication between an IDE or code editor (client) and a server which parses your code and provides code completion and other results.
The LSP standard is widely used in many IDEs and editors. There are some key benefits. One is that it is asynchronous: an editor will never pause, you can always keep typing. It is also a separate process to the editor or IDE, meaning memory usage improvements (lower memory usage in the client IDE, and entire memory space dedicated to code parsing in the server process.) Finally, LSP servers are available for many languages, and a LSP-aware IDE can provide features like code completion for any language simply by using a server, rather than having inbuilt support.
C++Builder has led RAD Studio’s LSP support, and 10.3.2 will provide fast, asynchronous, high quality code completion, parameter completion, error insight, and more. Notably, this means we already have LSP client support built into the IDE.
Delphi’s inbuilt code completion and error insight are areas we also want to greatly improve. Today’s error insight sometimes provides incorrect results - false errors - especially for new language features like inline variables. You may have seen incorrect ‘red squiggles’ in the code editor. We also want to improve behaviour for large projects with millions of lines of code, where today code completion can pause the IDE, or use a lot of memory while parsing a gigantic project.
We will answer this by extending the IDE’s LSP support to Delphi, and providing a native Delphi language server.
In the same way that language servers like cquery are based on compilers (cquery uses libclang, clang as a library), our Delphi language server will use the Delphi compiler at its core. This means the code insight you see, the errors reported, and so forth will be exactly accurate to how the compiler views code.
This means you will see faster code completion; the IDE will never block while completing; error insight will provide accurate results; and more. This is the largest and best improvement to Delphi’s code tooling in many years and we’re very excited about releasing it.
The roadmap this year is huge, with a large number of features planned. We have a big focus on quality and on improving or replacing systems to provide a better experience for our customers. We aim for significant and large enhancements both in functionality we provide, and to quality and productivity, for both Delphi and C++ customers.
This includes 64-bit macOS and Android platform support for Delphi, allowing you to distribute your apps to the macOS App Store and Google Play Store; further language enhancements for Delphi; greatly improved Delphi code completion, navigation, error insight and more. We’re also unifying all Windows compilers with the upgraded C++17 Clang compiler; and adding significant improvements to code completion, navigation, and insights for C++. There’s also high DPI support for VCL styles; providing a more powerful debugger for mobile and macOS; support for Google Firebase push notifications and related services; many RAD Server enhancements; and quality and performance improvements in the RTL, especially LiveBindings, the Parallel Programming Library, and HTTP client library, among others -- and more.
As you can see from the roadmap slides and this blog post, our roadmap includes a large number of features, and a large focus on quality including significant improvements to some of the core productivity areas in the IDE. These are all areas we’ve heard are important to you, and we’re greatly looking forward to what we will provide you in the upcoming year. Make sure you have update subscription so that you get each version of RAD Studio and these features and improvements as we release them!
Note: These plans and roadmap represent our intentions as of this date, but our development plans and priorities are subject to change. Accordingly, we can’t offer any commitments or other forms of assurance that we’ll ultimately release any or all of the described products on the schedule or in the order described, or at all. These general indications of development schedules or “product roadmaps” should not be interpreted or construed as any form of a commitment, and our customers’ rights to upgrades, updates, enhancements and other maintenance releases will be set forth only in the applicable software license agreement.
Reduce development time and get to market faster with RAD Studio, Delphi, or C++Builder. Design. Code. Compile. Deploy.
Start Free Trial
Free Delphi Community Edition
Free C++Builder Community Edition
DO NOT implement unllable types as managed records, since it will hurt performance a lot, and will make them practically unusable. Why nullable types requires managed records?
Because nullable types require initialization and records are not automatically initialized. Only managed fields inside records are automatically initialized. This fact is currently used in various nullable types implementation, but managed records automatic initialization would be faster than managed types initialization.
Why initialization semantic of nullable types need to be different from their not-nullable couterparts? Having in mind that simple Integer type is not managed (need no compiler initialization/finalization), why Nullable<Integer> need to be managed?
Zero-fill in class fields and array elements - is sufficient as with any other primitive types. Otherwise, IT WILL BE OVERKILL.
Just for note: - Objects with one string field constructed/destructed almost twice slower than objects without managed fields. - Arrays - even more slower. - Implicit try/finally is generated by compiler for each procedure/function, which uses managed types, for example:
procedure TList.Delete(Index: Integer);var Temp: Pointer;begin if (Index < 0) or (Index >= FCount) then Error(@SListIndexError, Index); ...end;
Why exception raising code is moved into distinct Error procedure? Because string values are used inside it, which requires implicit try/finally, which is slow.
While we know we need to focus on performance for low-level language features, and I understand the request, I think here you are mixing different levels and techniques. Strings are managed, heap allocated, and reference counted. Implementing nullable types that way will be overkill, I agree. But managed records (in the model we are planning and have been working on) are not heap based and not reference counted. Being "managed" only means you can have custom initialization and finalization code to be executed when the records is created and goes out of scope. But this doesn't need you must have it. Some additional exception management gets pushed in, and that is a (limited) cost. We'll optimize it. I'm not saying this is the only option for implementing nullable types, but this is a fairly flexible one and the main approach we have been considering.
I understand what managed record will be, including the fact that they have no direct relation to heap allocation. Basically, I'm personally asked about managed records in Quality Central several (a lot of) years ago. However, I initially thought about rare exotic use cases.
But, nullable types are too common, too low level. As you correctly mentioned, managed types requires "some additional exception management", which effectively generates implicit try-finally in every procedure which uses them.
Can you please answer my initial question: why exactly Nullable<Integer> need to be managed at all?
Also: when I wrote that objects with one string field constructed/destructed almost twice slower than objects without managed fields, I meant that string field is just need to be declared in class (no values need to be assigned to it, so - no additional heap allocations).
"Can you please answer my initial question: why exactly Nullable<Integer> need to be managed at all?" - how do you expect it to be null initially if it does not get initialized automatically by the compiler?
Why should I expect it to be null initially? Simple Integer local variables are equal to zero initially? No, and, no one bother.
So, may be it will be better to keep language consistency, and have same initialization rules for Integer and Nullable<Integer>? Providing well known "variable not initialized" compiler warning.
Maybe some of the discussion here is causes by a misunderstanding of the term "managed records". There a not managed = dynamically allocated in memory and the like. This will affect performance significantly. We refer to "managed records" as records with initialization and finalization code (that is, parameterless constructor and destructor) the compiler will automatically inject at the right place (declaration, going out of scope). This avoids more convoluted (and slower) alternatives in use today -- like injecting an interface in a record to trigger destruction code. As for a nullable type the "null status" requires some management and support. That's all. Goal is local and fast allocation and cleanup, not using a reference type for nullable -- that will be overkill.
Do you really read my answers? I've already mentioned that I perfectly understand difference between "managed" records and heap allocation. Beleave me, I know most of RTL internals very well, including currently commented out code for managed records.
So (I repeat, sorry), may be it will be better to keep language consistency, and have same initialization rules for Integer and Nullable<Integer>? Providing well known "variable not initialized" compiler warning.
I know, mentioned warning not working currently for records:
procedure TForm3.Button12Click(Sender: TObject);
if p.X > 0 then // No warning here
p.Y := 7;
...and so, making nullable types "mananged" you probably following most simple way, instead of "state-of-the-art" way, which we expect from Delphi team, and which is probably more complex.
Then, if you think, that initialization of Nullable<Integer> variables with null initial value is so important, why all other types (such as simple Integer) initialization is less important? Be consistent! Lets make all types managed then!
State-of-the-art way here will be to implement auto initialization of all not explicitly initialied local variables. Delphi already have this logic in compiler - "variable not initialized" warning. So, instead of the warning, compiler should be extended to inject inplicit initialization.
And we'll get consistent solution, which will not even slow down existing programs (because people usually initialize variables), and will not make new nullable types ugly.
But, thats slighty more complex to implement. However, its the best way for long term feature.
So, finally, implementing nullable types as "managed", you'll end up with a monster like Variant type, which is also managed, and not always require heap allocation - but slow and not usable in most low level cases.
And one more question: Will nullable types have its own enrty in TTypeKind enumeration - tkNullable (like tkArray, for example)? Otherwise, I wish everyone happy working with RTTI...
I wonder about Marco comment on this since egbbv is right there, we don't need bogus solution it's better to postpone it and make it later the most proper way.
Yes, Marco, please comment my post above.
Also, please, explain how low-level things, like sorting big array of nullable integers will work. I think it will be funny...
Can you comment words below of egbbv?