Clojure and Pull Request Controversy

[Chris]

On Thursday, 29 November 2018 at 06:17:11 UTC, Walter Bright 
wrote:
> On 11/28/2018 3:29 AM, Chris wrote:
>> I sincerely hope you don't identify with the OP.
>
> I did say it was controversial.

Funnily enough because they are too conservative, whereas D might 
have her refers to as "feature bloat". I'd call it overstretching.

>
>> Yesterday I was innocently thinking if and how LDC+Android 
>> could be integrated into Android Studio via CMake etc., but 
>> then it occurred to me that even if I / we succeeded in doing 
>> so, the D code itself might still break anytime, because of 
>> "more radical ideas". Maybe D should be rebranded as 
>> "Minefield".
>
> There is a disconnect with not wanting radical new ideas, and 
> wanting autodecode removed (which will result in silent 
> breakage).

You do realize that autodecode is an old flaw that has to go 
sooner or later. It negatively affects string handling 
performance, is not even correct and is a deal breaker in a world 
where string handling is omnipresent. So removing autodecode 
would benefit the language and the users in the long run and is 
both necessary and welcome. It's not a "new idea" you might want 
to try, it is strictly necessary, just like fixing the brakes of 
your car is not a "radical new idea", but necessary. And 
reasonable paths to fix it have been proposed.

However, coming up with "radical new ideas" about memory 
management and the like and making it a feature of the language 
that breaks valid existing code only to see what happens, is a 
baaaad idea. I'd suggest something like the "D labs" for it where 
you can test all those great new ideas and features for a minimum 
of one year. What if a feature turns out to be sh*it? What if you 
realize that partial constructors sound great, but you cannot 
have partial deconstructors? D should have a "laboratory branch" 
for this but not use users as guinea pigs.