If you could make any changes to D, what would they look like?

SealabJaster sealabjaster at gmail.com
Wed Oct 20 23:25:31 UTC 2021

On Wednesday, 20 October 2021 at 19:41:52 UTC, Kagamin wrote:
> Like many people here I tried to design my own language, but I 
> noticed that I can't get (logically) puristic concepts into an 
> adequate form. I grew suspicious it's because the problem 
> domain itself is impure, so puristic concepts can't be 
> adequate, and an adequate language should elegantly incorporate 
> impurity instead of evading it at all wasteful costs. I also 
> take this approach in program design, somehow a line is easy to 
> see that the component shouldn't be more pure than this.

I've tried as well, but lack of experience and lack of attention 
span has made this hard to achieve.

I had a crazy plan at one point to make my own assembler, then 
make my own language on top of that assembler, for whatever dumb 

The main point of this post was to explore what D could've 
possibly looked like, based on the ideas of the forum dwellers.

Here's a **very** rough estimation of other people's proposals:

class A {}
class B : A {}

// @safe, @pure, @nothrow, etc all applied automatically by the 
// Very small executable because we don't import phobos
// Slightly big executable because we use the runtime (GC)

void func(const(A)* a) {} // Adam's proposal
void funcb(const(B)* b) { func(b); // I assume upcasting still 
works }

void intPromotion() {
     byte b;
     b = 2 + 3; // byte
     b = b << 1; // byte

int* pointers() {
     int^ managed = new int;
     // Explicit nullable
     int*? raw = cast(int*?)malloc(int.sizeof);

     // ! == "Definitely not null"
     // Using the proposed || == x ? x : y syntax
     return raw! || managed.ptr;

void nullChaining(SomeClass*? value) {

More information about the Digitalmars-d mailing list