D community's view on syntactic sugar

[Jonathan M Davis]

On Friday, June 15, 2018 23:04:40 Sjoerd Nijboer via Digitalmars-d wrote:
> For someone coming from a C# background there is some seemingly
> simple syntactic sugar missing from D.

Typically, the approach right now is to do stuff in libraries rather than
the language if it's at all reasonably possible. The language is incredibly
powerful as it is, and we can do a _lot_ of stuff with libraries, frequently
without making it much noisier than it would be to put it in the language.
New syntax can certainly be added to the language if it's deemed to provide
enough benefit, but it really needs to pull its own weight. Where the line
on that really should be is often subjective, but ultimately, it's Walter
and Andrei's decision. Anyone who wants to add new syntax to the language
needs to write up a DIP for it with solid arguments that convince Walter and
Andrei that the language change is worth the cost.

> * The null conditional operator `?.`

It's been discussed before, and maybe we'll get it or something like it at
some point, but it really wouldn't help much with idiomatic D. The average D
program does a _lot_ less with classes than a language like C# does. Most
stuff is done with structs on the stack - especially with range-based
programming. That's not to say that certain types of programs couldn't
benefit from such syntax, but it's going to be a lot less common than it is
with C#. But it's also pretty trivial to write a helper function that does
the same thing if you really want a short-hand way to do it.

> * 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.

There has been discussion of adding some sort of async solution to the
language at some point, but the real problem here isn't the syntax. It's
coming up with what the syntactic sugar gets lowered to. That being said,
the question of whether anything like that is added to the language will
likely ultimately come down to if language support is really required to
make it work well. If it can be done cleanly without language support, then
that's probably what's going to happen, simply because Walter and Andrei
aren't big fans of adding to the language at this point if it doesn't need
to be added. However, I do recall some discussion that language support was
needed for some part of this, and if so, then it might happen. Regardless, I
expect that shared will need to be fully finished before we do anything with
trying to add any kind of async stuff to the language. Walter and Andrei's
focus right now is much more on finishing and fixing the features that we
already have rather than adding new ones.

> * a good syntax for properties so there's less code bloat.

If you want to be able to add a variable as well as getters and setters for
it in a single line, then you can easily do that with a mixin, so I doubt
that any further language support will be added for that. I believe that
there's at least one library on code.dlang.org that has helpers precisely
for this use case. Personally, I do like the idea of putting @property on a
variable to make it so that getters and setters are generated for it, but
it's exactly the sort of thing where the verdict is likely to be that it's
so easy to implement with a library solution that it's not worth adding to
the language. And truth be told, a library solution could easily be far more
powerful anyway - especially if you wanted to add a getter and not a setter
or if you wanted a way to do something like provide contracts for the
setter. While they might be slightly noisier syntactically, library
solutions are usually much more powerful - especially with all of the
fantastic metaprogramming features that D has.

> * 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?

new is a keyword, so turning it into a template wouldn't work very well at
this point. Based on what Andrei has said in the past, I fully expect that
if we were doing D from scratch, we'd end up with something like new!MyType
(instead of new MyType) where new is simply a templated function rather than
a keyword (and thus could be replaced with an alternate implementation), but
at this point, I think that that ship has well and truly sailed.

> 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.

We may very well get more syntactic sugar and other syntactic improvements
to the language if there's a strong enough argument for them (e.g. a DIP was
accepted recently which provides a more concise syntax for contracts), but I
think that you're going to have to look at what D looks like right now and
be willing to live with that if you want to use D. If the lack of stuff like
?. is unacceptable to you, then you're going to be unhappy with D, because
while stuff like that _might_ be added, the odds aren't great, and it's
definitely not a priority. If you can live without that extra syntactic
sugar and then consider yourself lucky if some of it does get added later,
then you may be very happy with D, but don't bet on anything like that
getting added.

In general though, if you're willing to use a helper function rather than
insisting on adding something like an operator to the language, you can get
all of that same power without needing any language changes.

- Jonathan M Davis