D community's view on syntactic sugar

[Nick Sabalausky (Abscissa)]

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 :(