I have an idea. Due to the abundance of D capabilities, I propose to introduce the concept of D profiles to the community. In D, you can write firmware for a microcontroller, an OS, a web server, scripts, a vst plugin, and a compiler. All these niches have different requirements from the programming language. We already have a betterC mode, but what if we introduce a more understandable gradation? Well-defined subsets, let's say. We call these subsets profiles. With these profiles you can better search for the required packages in dub. Let's say I have a system profile, and it will be possible to filter all packages by this request. A system profile may have requirements not only for the absence of GC, but also for the API in general, for example, to be closer to a low level. Or I have a script profile, I can use both system and script profiles. This will also allow language developers to see the weaknesses of specific profiles and introduce features for them. You can build std like a pyramid, with a system profile at the bottom, and a managment profile based on it, for example.
Here is the list of profiles I suggest:
CompileTime profile. This profile is the most universal, since it does not affect runtime in any way.
System profile. This profile uses a DOD (data oriented design) approach. Minimum classes, delegates. Error handling via values. Data is not live, scope(exit) instead of destructors. Using std.sumtype. If it is a library, full dip1000 support. If it is a library, std.experimental.allocators are fully supported. Can call gc code at higher levels, so the nogc attribute is not required. The code will have a lot of boilerplate around memory management and error handling, just like in C or Zig.
Application profile. Classes and interfaces are already available in this profile. Structures have raii. Garbage collector is fully accessible. Processing through exceptions is possible. Support for OOP and FP paradigms. There may be some kind of runtime reflection. Totally @safe.
Script profile. It mainly differs in its API in the libraries. It should be simple and flexible. This can be used as 50 line scripts for image processing, parsing, data analysis, conversion. Maybe it’s a library that parses a binary file based on UDA (like imhex patterns). This could be a library for prototyping something. Data visualization, plotting, etc. That is, what Python is used for. Perhaps the compiler will need support for parsing a module simply as a main function. Perhaps a selective level of optimization is needed (O2 dependencies, O0 script). You need a fast linker, or the ability of a compiler to link the code in jit and execute it right here.
What do you think? Should we split D into 3 languages with a common ffi?