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.
