Dlangs inconsistent decision making and ai

[Kapendev]

On Saturday, 29 August 2026 at 20:54:06 UTC, monkyyy wrote:
> D's political failures waste an extreme amount of effort and 
> has been an on going complaint for at least 2 decades, some 
> possible contributors may not have been born before the first 
> rage quit from dlang. I cant fathom how yall thought the half 
> completed wasm runtime should've been allowed to rot.
>
> This is incredibly stupid and Ive never seen the core team 
> acknowledge the problem or empathize with the outsiders.
>
> Wearing my politics on my sleeve, I believe the blunt force 
> solution to communication problems is clear ownership; when 
> Britain was a 2 month round trip by boat from america requiring 
> paperwork to physically travel by boat to get signed off was 
> retarded; the red coats may have been able to keep their empire 
> if they invested in fax machines in time. When decision making 
> breaks down, you move the decision making to be more local.
>
> If upstream is adopting ai, may as well use it. While my 
> historical suggestion to spread ownership around by shipping 
> 2nd party libs appearly was so beyond the pale to be considered 
> for a even moment. It seems to me you can get ownership-like 
> effects with ai.
>
> Instead of a fucking half-baked "lets say no by default" "you 
> MUST describe your problem to half deaf ears, with possibly 
> weeks of delay of communication" polices; construct personality 
> profiles on representatives to review pr's and assign ownership 
> by file with %'s.

I had an idea like that recently on the D Discord server.
You could make a friend list for every D module.
A friend is allowed to modify anything, even a private field, 
while a simple acquaintance is forced to follow the rules set by 
the master and his friends.

Example:

```d
module std.json;
pragma(friends, "master:serg:user1234");
```

This idea can be extended to include things like ownership of a 
file.
For example, only friends are allowed to import a module.
Friends can be defined via CLI arguments.
An optional password could be passed for enforcing extra module 
safety.
That one actually might be a great step towards "Spatial Code 
Safety" as some people call it online.

> Consider std.json, theres a file json.d, everyone hates it I 
> wouldnt even want "ownership", the natural place to assign 
> ownership is on ceo's of any of the corps that have made the 
> unfortunate misinvestment to depend on it.

You will get ownership and you will be happy.

> new code in the std

What we want is librarymaxxing and dependecymaxxing.
STDs are bad. Spreading them is even worse. Search "STD" right 
now on Google or DuckDuckGo (or ask an AI), and tell me if it's 
really good or not. I can wait.