D Profiles Idea

[Mensikov]

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?