Features of D That I Love (bradley.chatha.dev)

forum.dlang.org is also written in D.

.init is not necessarily 0. For int it is, but for float it's NaN. For char it's 255 and for an enum, it's whatever you have decided it is. enum thing { first = -1, second, etc. } This way, a variable of type thing has -1 as init value.

>The "invariants" thing is fantastic, I haven't seen anything like that before and it's great.

is it not the same as the one in Eiffel?

I feel like this feature could be implemented on top of more universal features.

Checking input parameters is easy, just write asserts at the start of the function.

Checking result requires "destructor" block and some kind of accessible result variable, so you can write asserts in this destructor block which you can place at the start of the function, as well.

Checking class invariants requires a way to specify that some function should be called at the end of every public function. I think, it's called aspect-oriented programming in Java and it's actually useful for more things, than just invariant checking. Declarative transaction management, logging.

There are probably two schools of programming language designs. Some put a lot of features into language and other trying to put a minimal number of features into language which are enough to express other features.

See Design By Contract, and the language that brought its ideas into mainstream, Eiffel.

What D or C++26 can do, is a subset of Eiffel capabilities, or more modern approaches like theorem proving in tools like Ada/SPARK, Dafny, FStar,...

> It's a mystery why D isn't far more popular than it is.

There's no mystery. It's a jack of all trades, master of none. E.g., the virality of the GC makes it a non-starter for its primary audience (C/C++ developers). The need to compile and the extra verbosity makes it a bad substitute for scripting like Python. Etc.

Basically, name any large niche you'd expect it to fill and you'll probably find there's a tool already better suited for that niche.

Mostly wrong place at the wrong time, I guess :(

Plus the chicken and the egg problem. This is mostly from the AerynOS experience : it seems like if you want to write some moderately complicated code then you're becoming the upstream of many libraries. Especially now with Rust's popularity and ecosystem maturity on the rise, it's super hard to convince people (e.g. your boss) that you'd be better of with D compared to e.g. Rust.

IIRC it was weird and not that great in D1 era, and stalled for a very long time. There were also two competing incompatible runtimes.

Then came the D2 re-write which broke backwards compatibility and took another few years.

In the meantime everyone moved on

Articles like this I guess. If these are the 'lovable' features I'd hate to see the 'meh' features.

Automatic constructors - You only have to write the 'make me a box of two apples' code and not 'this is how two apples go into a box'! This is as revolutionary as 'automatic function calls', where you don't have to manually push the instruction pointer to pop it back off later.

Parenthesis omission!

If I were to parody this I'd talk about how good Scala is - in addition to classes, you can also declare objects, saving you the effort of typing out the static keyword on each member.

Sell me something nice! Millions of threads on a node. Structured concurrency. Hygienic macros. Homoiconicity. Higher-kinded types. Decent type inference. Pure functions. Transactions.

I needs a "Django", "Rails", "ASP .NET" type of project that is out of the box ready. Go has net/http out of the box. I think if D had either a batteries included (Vibe.d is nice, but you have to handle some things still) web framework, it might convince some folk to use it more.

Go spread the way it did because it was dead simple to make websites and services, the syntax is insanely simple, but the language allows you to scale without going through a ton of hoops. Look at how much of our IT infrastructure is powered by Go now.

D has a lot of potential, but someone has to sit down and build frameworks and tooling for D.

I think if D had officially supported libraries by core maintainers that take full advantage of the best of D it might be a different landscape.

Another area where D could shine is GUIs. Everything is electron these days, it feels like nobody builds usable GUI stacks. If D had an official solution to this, and it worked nicely and gave you enough power to customize your UI, we might see a shift there too. I welcome a Electron free future.

Look at the Zed editor (ignore the AI buzz) and how insanely fast it is. Its coded in Rust, and uses WGPU iirc to just render everything kind of like a video game, but it runs insanely fast. It is my new favorite text editor.

Sadly despite my deep love of D, Go is where I'm leaning more towards, due to industry pull there.

Lack of sufficient tooling support was my issue. Debugging and autocomplete was a flaky mess in VSC. The plugin for VS pro wasn’t much better.

I did not like DUB at all. Its default behavior was to not segregate artifacts by configuration, and trying to change that was a headache.

It’s too bad, though. It’s a nice language, but I can’t see it making any inroads at this point.

Reminds me of vim script's implicit method syntax [1]

Eg. any function call can be converted to a method call on the function's first parameter:

    let mylist = [3, 2, 1]
    " prints "1" as these two are equivalent
    echo sort(mylist) == mylist->sort()

Helps a lot with chaining.

I was about to say "Yeah, its my favourite feature of Nim!" and then I realised what account I was replying to ;)

OO support is more than just record.method(), which is something you don't even have in OOP systems based in multi-dispatch.

> When you have UFCS you can toss out 90% of the uses of methods in favor of just plain ole functions.

Can those go away if you use inheritance or polymorphism, and you need your functions to access protected or private members? I mean, OO is as much about methods as functional programming is about functions.

I'd love to see more of these. In fact, I think it would make an amazing language feature zoo. Mine are heredoc, underscores to format large number 8_098_162_123

I don't see why it would be a terrible idea. It's pretty convenient if you're slicing a multidimensional array.

> i believe the only contender is julia

C# has "^n" notation that means "length - n". For example:

Take the last element of an array or any other structure that supports indices:

    var a = ar[^1];

Take the last three elements of an array or any other data structure that supports ranges:

    var lastThree = ar[^3..];

I'll take this:

    Vec2 result = translation + (rotationMatrix * (scalingMatrix * point));

Over this:

    const result = vec2Add(translation, mat2MulVec2(rotationMatrix, mat2MulVec2(scalingMatrix, point)));

Anytime

And that's a very simple example, in Zig, that kind of equations doesn't scale well, when it comes to readability

I was wondering the same thing. I have done a few toy projects in Zig, but found some of the docs lacking when you start to get into the weeds.

Honestly the main reason UFCS is good is when you don't "own" the type your function would need to be a member of. Most common one I run into is the "to" function from the stdlib. You can do this:

    import std.conv;
    
    int foo=3;
    string bar = foo.to!string

But now lets say you want to convert ints to MyCustomInts? You can hardly attach a new "to" member to int, but with UFCS it's easy. Just declare a to function anywhere in scope:

    MyCustomInt to(T)(T v) if(is(T==int)){
        return MyCustomInt.from_int_value(v)
        // or however you actually do the conversion
    }

and it'll magically work:

    int foo=3;
    MyCustomInt bar = foo.to!MyCustomInt;

Yes, a subtle but very important point!

> function arguments can be "in", "out", "inout", "ref", "scope", "return ref" - and combinations.

None of them are required. What they do is provide enforcement of semantics that otherwise would have to be put in the documentation. And, as we all know, function documentation is always either missing, outdated or just plain wrong.

For a (trivial) example:

    void foo(int* p) { *p = 3; }

vs:

    void foo(out int i) { i = 3; }

In the latter, you know that `i` is being initialized by the function. In the former, you'll have to rely on the non-existent documentation, or will have to read/understand the foo()'s internals.

`out` definitely is a win. Let's look at `scope`:

    void foo(int* p) { static int* pg = p; }
    void bar(*) {
        int x;
        foo(&x); // oops
    }

vs: void foo(scope int* p) { static int* pg = p; } // compiler flags error

This is most definitely a memory safety feature.

> The source code for the C++ standard library is much worse, of course

But you prefer C++?

(The D standard library is in the process of being re-engineered for clarity, but still, it is far more comprehensible than C++'s.)