I do realize, perhaps not the best wording on my part. Isn't Chalk going to be the part of the compiler though? I see it as a multi-purpose effort: making the compiler smarter (this is where it affects language design) while improving the architecture of its code at the same time.
I also agree that fixing language-level inconsistencies is great. Small improvements and making existing constructs more powerful using incremental steps is fine with me, and they are explicitly not the issue I am talking about.
What I was referring to is large and mostly additive changes (which IMO often make inconsistency worse in fact). These are usually not the ones you propose; they are being scattered all over GitHub and IRLO…
sure, here are some recently-posted proposals which are mainly additive and I think not as important as the others I enumerated above:
As for the examples of features being accepted despite considerable controversy: default binding modes and impl trait in argument position.
Sure; I even explicitly wrote "compiler or other infrastructure" this time. I appreciate the work of both teams, and yes, "T-Lang should substantially reduce the number of accepted proposals". This doesn't contradict that other teams should continue with what they are doing – quite the opposite, in fact. Both compiler work and smaller-scale language design polishing is great – I would just like to see fewer radical and large-scale, high-impact changes to language design.
I don't understand why "blocked on language design" is being used as a counter-argument here; design is just as important in the lifetime of a feature as implementation is. Furthermore, it's not primarily the age of the individual features that bothers me. Rather, it is their much more fundamental and "simpler" (from the user's point of view) nature. In other words, it just feels wrong to get lost in discussions about sophisticated and complicated new ways of creating enums, writing loops, or overloading the assignment operator, when all I wanted is Box<Read + Write> (which is something quite natural to want IMO).
That's a perfect example: it's a small change which improves consistency by allowing something to be arbitrarily nested whereas previously it was a top-level-only construct. I think RFCs like this are always welcome; this is exactly the kind of polishing I was referring to earlier. I'm not against small improvements like this, because they do drive the given language feature towards completion, and they don't focus disproportionately much effort and/or attention.
I'm only against big, overly ambitious changes while there's still lots more to flesh out. I realize that we might have different definitions of what's "fundamental", so the disagreement might stem from this.
We agree on this completely.
Sorry, it was indeed not the best way of putting this (let me change it in a moment). I wanted to ask why isn't more work being focused on it? I realize that the speed of getting things done doesn't increase linearly with the number of people working on them, but what I was trying to suggest is: isn't it possible for more people to (temporarily) join the anti-tech-debt special task force? Of course the motivation being that I think this is more important than continuously acquiring new features, which you disagree with.