On the future of D lang

https://forum.dlang.org/post/rcnrixuppxflnrheyvsz@forum.dlang.org

Send me your list of D gripes and wishes

Well, you asked...

"You shouldn't want that"

assert(" 2".to!int==2);//Unexpected ' ' when converting from type string to type int

Frequently I want something other people view as insane, such as fault-tolerant type conversations, file io in ctfe, or std.containers to be updated before allocators are merged into the language.

Fundamentally I don't think this is ever an acceptable response to such questions, yet it's often the party line. Not to be confused with "this slightly different code works", but people telling me that "you are wrong for wanting that". All it does is end the conversation with me being annoyed with the community, it does little to drive forward a solution. Furthermore, D is a flexible language, with `betterC`, with a community of meta-programming hackers, people will just ignore you and if those fractures of the community run deep enough, well people will go make their own language.

Ranges should be hacky, interfaceless, and simplified and have adequate data structures

I think of ranges as a struct with 3 mandatory functions and some optional functions. This explanation will get you surprisingly far, nonetheless the std attempts to enumerate all possible versions of the interfaces such as `RandomAccessFinite` with complex headers and several specialized implications. 

I think this is a failure; it won't always work so don't try; simplify the system, if an algorithm fails to compile with a strange edge case of a range; provide hacks, and make the code simple and readable so they can edit their own version. Have composites algorithms; specialized algorithms for edge cases; dozens of data structures. Build up an ecosystem of simple pieces that 90% of the time will combine to make a solution. As it stands the interface that makes it easy to combine data structures and algorithms has few data structures, has overly formal algorithms that are hard to understand for even me. There are known hacks to make things work but they have to be copied and pasted around from old projects.

Stop pretending D is a corporate language

There's a formal meeting, there's a yearly school community building program, and there's a formal process with many rounds of review for any and all compiler changes; none of which seems inclined to address anything I care about. Stop.

You have a community of meta-programming-crazed iconoclasts, who can and will make their entire toolkits like Adr, or the 5 or so people who went off to make their own language. You are simply not Go where you can have strict idiomatic language and the std is funded with google money. Or C++ where Microsoft with Enterprize-Grade mediocrity implements whatever API you put out.

Either you believe this small community has great 1000x programmers or you don't and we are doomed anyway from lack of manpower and money. You should be giving the 1000x programmers their sandboxes to let them shine, and push them close enough together they can see each other, but walls to denote which sandbox is whose.

Suggestions

Start the "D3 std" project, yesterday, with a distinctly flexible structure. If Adr says "I want to make a color lib", don't stand in his way give him the namespace std.community.color that can be written to his style guide, to his standards, on his github, and when a new version of the compiler ships a script will grab a snapshot. Give it a few months to see if the experiment plays out, if not delete lib from the std.

Rip apart the dip process down to just the community review and a well-written template.

Refocus the people willing to play ~~with others~~ with the official style guide to fixing compiler bugs, and delete old unmaintained parts of the std.

Don't herd cats, just clean out the litter boxes.