On Wednesday, 29 October 2025 at 16:18:22 UTC, Paul Backus wrote:
> On Wednesday, 29 October 2025 at 13:55:42 UTC, jmh530 wrote:
> You say it's a "major change to the language". Is it really? I thought private(this) was added to Open D without much difficulty.
It's a change to the grammar, which means that all parser-based tooling (DCD, DScanner, serve-d, etc.) would need to be updated to support it.
Hmm, I don't have a sense of how much of a lift that is. But I think it comes back to putting the burden on the people who support the DIP. Make a list of tools that need to be updated and say the DIP is only approved if they update those to support it.
> > It's also occasionally more difficult to split up code into multiple modules. For instance, what if you are prototyping something in run.dlang.io (impossible I think in this case)
You can actually have multiple modules on run.dlang.io, using the following syntax:
--- lib.d
module lib;
int fun() { return 42; }
--- app.d
module app;
import lib;
void main()
{
assert(fun() == 42);
}
Sorry, I think I knew this but had forgotten.
(Jonathan Marler who wrote the HAR code left the D community for Zig, might be something that the DLF could take over)
> > With respect to the secondary arguments:
- On the mental complexity budget issue, I don't view that as a big issue as it is a convenient extension of the protection modifiers.
protected and package are probably more confusing than this.
Managing overall language complexity is the #1 challenge in language design. If you don't take this seriously, your language ends up like C++ or Perl--a huge mess that nobody really understands completely. (You could argue that D has already crossed this line, but even if that's true, it doesn't mean we should make it worse.)
Even features that are small and simple in isolation can add up to an enormous amount of complexity if you accumulate too many of them (see: Perl). So the fact that this individual feature is relatively simple is not a strong counterargument.
The optimal amount of complexity isn't zero. Obviously.
As with all things, there is a trade-off, whether that's against performance, expressiveness, etc. If all you care about is complexity, then you would never add any new features. It's an argument for setting things in stone (and I thought the whole point of editions was to allow the language to evolve).
The argument about complexity is most convincing when it is phrased like "this feature adds complexity without generating enough of an improvement in performance/expressiveness/etc" (or from a second-level basis something like if we add this feature now then it may place a higher burden on adding additional features).
In this sense, it is a question of marginal cost (complexity) vs. marginal benefit (performance/expressiveness/etc).
On the marginal cost side, there are lots of different kinds of complexity. What you responded to was me talking about cognitive complexity. I happen to think that's really small here. But people can disagree. The complexity I would be more worried about is the impact on the compiler code base. I don't have the ability to speak to that, but I take people like Dennis and Walter at their word that it's something to be concerned about. But if the argument against it is that complexity will increase, then the argument carries more weight if we can spell out more concretely how it will increase.
On the marginal benefit side, there are clearly people out there pounding the table for this feature, even if it's not that important to most.
My point is that I don't think it's a slam dunk in favor of adding this feature, or for that matter saying no. I think it's something that should get weighed.
This complexity vs. expressiveness trade-off shows up in a number of places in D. The string interpolation debate was one example where a less complex solution was proposed and was loudly shouted down in favor of a more complex and more expressive solution (and led to the creation of openD). When DIP1000 was originally discussed, the approach was argued for as less complex than a more generally expressive approach. And we're still debating these issues now, like 9 years later. Sometimes the more expressive approach will be less demanding from a cognitive perspective, even if it is more complex to implement.
At the top I said the optimal amount of complexity isn't zero. Even something like the trade off between complexity and performance/expressiveness/etc., we would be trying to evaluate the language on a more-or-less objective basis. Another way to think about it is whether adding a feature will mean more projects get written in D than otherwise (or even better consider something similar that incorporates profits or some measure of value-add) (note: I don't mean actual people writing actual projects per se, so much as hypothetical people writing hypothetical projects). This could also account for second order effects where if the feature makes D harder to implement other new features or have higher cognitive load, then it would impact the trajectory. This framework would suggest that if has a first order impact of getting more people to write more D projects (esp. if they are projects with positive value-add) with limited second order impact, then it should be given a reasonable considered, especially with Editions being added to the language.
The D leadership has built a really cool programming language, but it's still a niche programming language. And I don't see much on the horizon to change that. If they want it to stay a niche language, then that's fine. If they want to make it a more popular language, then they might need to change the way they think about some of these issues.
Permalink
Reply
