No we should not support enum types derived from strings

[Mathias LANG]

On Monday, 10 May 2021 at 22:58:41 UTC, deadalnix wrote:
>
> Sure, but look at this thread. D is crumbling under the weight, 
> not of the number f feature, but of the fact that a large 
> portion of them simply are unsound.
>
> At this point, the decision made is to push the madness on the 
> user. Fair enough, but if the standard lib devs are not willing 
> to put up with it, why in hell would you expect anyone else to? 
> Just look at what's in the C++ standard lib or boost and 
> compare to your average C++ project to see the kind of gap in 
> term of motivation to put up with bullshit exists between 
> standard lib devs and Joe coder. It's not even close.
>
> This stuff ain't working properly so let's just given getting 
> to work at all is not how you iterate toward a great useful 
> product.

Well, this thread is 11 pages and show no sign of winding down.
In the meantime, has anyone looked at the code that sparked this 
outrage ?

[As I mentioned in the 
PR](https://github.com/dlang/phobos/pull/8029#issuecomment-834221552), the issue wouldn't have happened if the `fmt` template parameter was a `string` and not an `alias`.

> Q: why is fmt an alias and not a simple string ?
> A: No real reason.

The way I see it, the issue is valid, the fix wasn't. `format` 
API should have accepted a `string` and let the compiler perform 
any allowed implicit conversion, instead of taking exactly the 
type via `alias`.

I wish our most competent contributors would find it more 
interesting to direct their attention to Github or promote the 
language to their large Twitter following over engaging in 
flamewar.