Reimplementing the bulk of std.meta iteratively

[Andrei Alexandrescu]

On 9/29/20 12:56 AM, Paul Backus wrote:
> The best we can hope for is to nail down a precise description of all 
> the fiddly corner cases, so that we know what D's semantics *actually* 
> are, rather than what the current spec pretends they are.

Definitely. I'd go even further and call that "survival". C++ has had 
tremendous success with meticulously documenting all of the odd things 
they baked in pre-standardization. And then it was a matter of updating 
things, and it all got better. Most importantly, there was and is a 
group of people who understood the vital importance of that.

> But even that 
> is likely to be infeasible in practice--who wants to volunteer to be the 
> one to go over, say, funcDeclarationSemantic with a fine-toothed comb, 
> especially after what happened to the last guy? [1]

Actually Walter made a lot of efforts to do that, too, as he very well 
understands the importance of correct specification. But nobody cared 
about his related PRs, which probably are flapping in the wind to this 
day. He has some work on defining the object model, too, which has also 
been ignored. A kernel of 3-5 strong souls to commit to this would be 
very necessary. Walter can't do all of this alone. Now he can't even do 
it formally because of the "no single person" rule.

I should add I've been unfairly harsh about Walter's inclination to do 
tricks in the compiler. That applies a lot more to the early days than 
now. As of now our views are aligned to a large proportion on core 
language vs. library features.

> The fact is, there's no incentive for anyone to do this kind of work 
> other than masochism and sheer stubbornness. The amount of effort it 
> would take, and the amount of time that would pass before you saw any 
> benefit, are simply too high. We can talk about principles and good 
> engineering all we want, but we can't expect people to voluntarily act 
> against their own interest.
> 
> Maybe we can make some improvements at the margins, but my prediction is 
> that the overwhelming majority of D's complexity is here to stay, 
> whether we like it or not. The best we can do is try to offer enough 
> positive value to D programmers to offset its negative effects. And if 
> it doesn't work out, well, there's always Rust. ;)

I think things can be managed, but documentation and control are a must. 
FWIW I don't think Rust fares that well in that area - it's a very 
complex language, with the complexity mostly in the wrong places leaving 
mediocre handling of all that's interesting, and its rigorous 
documentation is greatly outmatched by its marketing brochures.