D community's view on syntactic sugar

Bauss jj_1337 at live.dk
Sat Jun 16 08:05:12 UTC 2018


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

This has been discussed many times and would definitely require a 
DIP and a good usecase. I'm all in support for this one.

> * Something like a `yield return` statement for coroutines.

D has ranges and doesn't need statemachines like C#.

> T* he `async` & `await` keyword from C# make proactor pattern

D uses fibers and calling the yield() function has pretty much 
same behavior.

The major difference is your async code looks synchronous and 
thus more natural.

D is a clear winner on this one IMO.


> async code extremely easy to reason about.

See above.

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

I agree with this, but will probably never happen.

> * replacing `Allocator.make()` with `new!Allocator`. After all 
> `new` can be concidered as just a wrapper around the standard

Not sure about this. The less ties the language has to the 
library, the better.

> GC allocator. Why can't we just have a special template of it?
>

Above.

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

All in all.

D requires a DIP for each and very good usecase. Not just "I 
think they're useful and I'd like them"


More information about the Digitalmars-d mailing list