D community's view on syntactic sugar

[DigitalDesigns]

On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer wrote:
> For someone coming from a C# background there is some seemingly 
> simple syntactic sugar missing from D.
>
> * The null conditional operator `?.`
> * Something like a `yield return` statement for coroutines.
> T* he `async` & `await` keyword from C# make proactor pattern 
> async code extremely easy to reason about.
> * a good syntax for properties so there's less code bloat.
> * replacing `Allocator.make()` with `new!Allocator`. After all 
> `new` can be concidered as just a wrapper around the standard 
> GC allocator. Why can't we just have a special template of it?
>
> I have realized that I have become quite dependant on syntactic 
> sugar to the point that it severely impacts my productivity 
> when I work whitout. And these ones are my biggest obstacles 
> when I try to work with D from a C# experience. I think that C# 
> really nailed down some of these particular examples except the 
> last one of course.
> And I also think D could do a better job of embracing 
> productivity through supporting syntax of common tasks and 
> borrow from other languages in that regard.
>
> But the most important question is how other people feel about 
> that.
> If people hate syntactic sugar D will never become that gem for 
> me that I would like it to be. But if key people want it, it 
> one day might.

They are generally vehemently against anything that will make 
programmers lives easier unless it can be implemented as a 
library solution. They err on the side of library complexity vs 
compiler complexity even if the feature adds no additional 
complexity.

This is a good thing because most things that one wants to do can 
be done as a library solution with only a more inconvenient form. 
In the long term it is better to litter the library with poorly 
thought out "features" than poorly thought out features being 
permanently lodged in to the compiler/language. Of course, their 
is depreciation... This also allows one to "depreciate" without 
"depreciating", but at least it's easy to back up a source code 
library and all the dependencies of to that library and the 
compiler and all those dependencies of those dependencies. With 
modern TB drives we can now create a near continuous recordings 
of the state of a program and never worry about anything becoming 
stale.