On 06/15/2018 07:04 PM, Sjoerd Nijboer wrote:
For someone coming from a C# background there is some seemingly simple
syntactic sugar missing from D.
Everyone here is probably going to be different (D programmers are a
varied bunch), but for me, I absolutely love syntax sugar. And I very
much miss the earlier days when D was all about the sugar.
* The null conditional operator `?.`
I'd certainly love to see that in D. Or at least an equally good,
umm...equivalent.
* Something like a `yield return` statement for coroutines.
I have been itching for this SOOOO HARD. And I've not been quiet about
it either ;) I used to be just as much a C# developer as D (back around
.NET 3 or 4 IIRC), and as much as I love D, this is the one thing from
C# I miss soooo badly it drives me crazy.
Granted, we *can* do an equivalent via our old opApply feature, and even
spruce it up with some mixin-based sugar. But it *only* works with
foreach and it lacks the ability to integrate with ranges. And that's a
bit of a deal-breaker because ranges have (for very good reason) become
a standard D best practice.
We *can* also do it via fibers (there's even something in the std lib
for this), but that adds extra context-switching overhead to every
iteration. Depending on what you're doing it might not matter OR it
might make an order-of-magnitude difference in performance. So it's not
an all-purpose solution, and D normally tries to be all about aiming for
all-purpose solutions (which is one thing I really like about D).
Sht, even *C* can do this via the sweet protothreads library.
Unfortunately, the approach C's protothreads uses doesn't work in D. It
just happens to hit upon one of the FEW limitations in the features D
uses to (mercifully) replace the preprocessor.
Honestly, I could rant endlessly about the need for a yield/coroutine
syntax for D's input ranges (maybe even forward ranges, too???),
and...I've done so often, so I'll stop myself now... ;)
T* he `async` & `await` keyword from C# make proactor pattern async code
extremely easy to reason about.
Those were added to C# after I had left the language[1], but they
certainly sound nice and clearly have a strong loyal following. I for
one would welcome it, but I have a feeling D is probably closer to
handling the same use-cases from alternate directions (like vibe.d's
implicit automatic fiber yielding, or the futures-like approach used by
parts of std.process).
[1] Granted, I am doing more with Unity3D now, but Unity's C# is kinda
famously behind-the-times. And even though they finally updated it a
bit, async/await still aren't quite 100% there if I understand
correctly. So again, no personal experience with async/await here, but
it does sound nice.
* a good syntax for properties so there's less code bloat.
That bugged me for awhile, too, due to my earlier C# experience. But,
I've learned to live with (and even start to like) D's approach of
setters/getters mostly just being ordinary functions. It *does*, at the
very least, have the benefit of one less level of indentation - which
may sound trivial, but I really do find that code which requires less
indentation (and therefore has less nested scope) tends to be easier to
read and understand.
But C#'s approach does strike me as a little cleaner and less ad-hoc
though, IHMO. But FWIW, if you're coming from C#, I think D's properties
*are* something you can get used to. (And TBH, in D, I would simply
replace any C# use of the all-defaults "string blah { get; set; }" with
plain old ordinary data: "sting blah; // Done. So it's not a
property....whatever...")
What I'd REALLY like to have (in ANY language) is better control over
"read vs write" accessibility: If I could mark a variable as
publically-readable and privately-writable, I think that alone could
eliminate many typical uses of properties. After all, that's one of the
most common patterns for properties. And a rather tedious one, at that
(IMO).
* 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 like it FWIW, but I'm still not all that familiar with D's new
allocators yet, so I wouldn't really know.
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.
Honestly, I agree. Even though I left C# in favor of D (because D's
low-level features and metaprogramming made me feel *far* less
constrained overall), I really, really, really do wish that D still
valued syntax enhancements like it originally did (and C# still does).
That was a big part of what drew me to D in the first place. Now, D's
direction and steering tends to feel far more C++-esque to me (whereas
before it was the anti-C++ and pretty much billed as such), and I find
that majorly disappointing.
If only D hadn't given up on the AST macros idea, we could actually
implement most of this sugar AS A LIBRARY SOLUTION, just like modern D
wants.
AST macros are seriously awesome though:
There's this one CLR language, Nemerle, kind of obscure (and kind of
dead-ish now unfortunately), that has this one really weird, stupid
limitation: If you want an "if" statement WITHOUT an "else", you have to
say "when" instead of "if". Stupid idea. *BUT* the language supports AST
macros. So in 12 lines of code (Yes, twelve!!!!), I added support for
"if without else"...IN LIBRARY!!
https://github.com/Abscissa/plainIf/blob/master/plainIf.n
Seriously, AST macros turn a language into "LISP without
parenthesis-hell". So freaking awesome. Wish D hasn't given up on them
in favor of ugly unhygienic string mixins.
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.
Unfortunately, the current state of D's leadership is that
language-level sugar is to be STRONGLY avoided. I still think D is a
fantastic language, in large part BECAUSE of the designs which were put
in place during D's more flexible years. But regrettably, even if D does
become open to such things again, I don't see it happening anytime soon...
Unless, that is, if there's a major for-profit business invested in D
that strongly pushes for a feature (that's how D got it's much-beloved
user-defined attributes even while it was already moving well into the
"less language-level changes" philosophy it's in today). *Then* you
might be able to get something done. One thing D is kinda starving for
is respect and getting strongly backed by real-world business. We have
some, but we're kinda desperate for more. So THAT's the one big thing
that could provide leverage. But short of that...no sugar is likely to
happen anytime soon that isn't library-based, I'm genuinely sorry to
report :(
