This Week in D

What if I were dictator?

Blog
Posted 2020-04-06

What would I do if I were made dictator of D? More below.

Core D Development Statistics

In the community

Community announcements

See more at the announce forum.

Adam's rant box

If I were dictator of D, what would I change? Well, let's throw out some ideas.

The language

If you've been keeping up on this blog, you'll already know some of it: I'd implement my string interpolation and attribute proposals. But other than that, I'd mostly want to just shut down most change and focus on solidifying what is most used.

For example, I want better error messages. If a language change is necessary to enable that, we'll look into it, but otherwise, I'd rather leave the language as is and focus efforts on making it work better. I'm not really interested in new users, instead I'd want to focus on practical improvements for existing users.

The standard library

I'd want to change Phobos development to be more decentralized. No, not just "everyone depend on package managers", but sort of like that. Have independent authors work on their own, and then if we want to pull it into the standard library, the Phobos devs are responsible for making sure it still builds, but actual development is still done independently.

Basically, the stdlib is a collection of long-term support branches of select community libraries. The module names would include major version numbers to facilitate opting into breaking changes.

Removing things from the library would be very rare. There'd have to be some short term breakage to adapt the names to the version scheme, but after that, I'd try to avoid it.

Getting something into the library would be fairly easy, I'm of a "batteries included" mindset - just remember the development remains independent. All the author would have to do is follow the stability guidelines and commit to long term support.

Deep dive in versioning

I'm sure some of you are like "why version that way, just use dub's semver", but there's a key difference: module names provide more clash conflict resolution.

Consider an application that requires lib X version specifically 1.0, and lib Y, which requires lib X version >= 2.0. It's not gonna work - they require incompatible versions. Even if you compile them separately, you're going to get linker and/or ABI conflicts.

With D's modules though, there's solutions to all this.

  • The app can import libx = libx_1; and the lib Y can import libx = libx_2; and they happily coexist.
  • There's no binary conflict since the major version number is part of the mangled name.
  • Data types are independent as well, and conversions can be done inside the library by having version 2 literally import version 1's definitions.

There's a bunch of code duplication possible (though that might be mitigated by having version 2 import version 1, then redefine just the breaking parts), and doing backported bug fixes is an exercise left to the reader (possibly you could do it independently as git branches then apply the patch and check out things for the deploy), but it'd work fairly well for the users. They should be able to just consistently get the newest versions of the stdlib distribution without worrying about breakage.

I've long thought about doing this but never actually have, so maybe it won't work as well as I think, but definitely worth a try.

Documentation

I'd immediately switch to my generator, of course!

Blog Articles
Page generated by adrdox