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.

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.

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

e.g. SafeAccess

https://github.com/BBasile/iz/blob/7336525992cb178ead83a7893a5a54597d840441/import/iz/sugar.d#L1551

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

The library solution only has the downside of requiring parenthesis:

https://dlang.org/phobos/std_concurrency.html#.yield

> T* he `async` & `await` keyword from C# make proactor pattern async code extremely easy to reason about.

There was some talk about adding async/await to the language once we actually get an eventloop library into Phobos/DRuntime.

A very promising approach and project: http://dconf.org/2018/talks/olshansky.html

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

It's typically solved with `mixin`.

https://github.com/funkwerk/accessors
https://github.com/funkwerk/boilerplate

There's also somewhere on this forum a nice mixin that generates default constructors for you if you don't need any specialization.

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

How would you pass a reference to the allocator object around with new!Allocator?

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

Don't get me wrong, I like convenience features too - I was just trying to point that for most of these things a library solution is just one keystroke more effort and allows more rapid iteration on the design.

So of course, people obviously like syntactic sugar, but the problem is that nowadays one needs a strong argument when trying to convince W&A for introducing yet another language feature as it bloats the language and makes it harder for newcomers to learn it and read code in it. Also in the past a few language features haven't turned out to be that great, so that's why nowadays there's more caution.
However, there's quite an interest and we regularly do get new sugar, e.g. the new contract syntax:

https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1009.md (will be part of the upcoming 2.081)

On Sat, Jun 16, 2018 at 12:20:35AM +0000, Seb via Digitalmars-d wrote:
> 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 `?.`
> 
> e.g. SafeAccess
> 
> https://github.com/BBasile/iz/blob/7336525992cb178ead83a7893a5a54597d840441/import/iz/sugar.d#L1551

Didn't Andrei propose an Elvis operator some time ago?  Whatever became of that DIP?


T

-- 
Just because you survived after you did it, doesn't mean it wasn't stupid!

On Saturday, 16 June 2018 at 00:32:24 UTC, H. S. Teoh wrote:
> On Sat, Jun 16, 2018 at 12:20:35AM +0000, Seb via Digitalmars-d wrote:
>> 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 `?.`
>> 
>> e.g. SafeAccess
>> 
>> https://github.com/BBasile/iz/blob/7336525992cb178ead83a7893a5a54597d840441/import/iz/sugar.d#L1551
>
> Didn't Andrei propose an Elvis operator some time ago?  Whatever became of that DIP?
>
>
> T

https://forum.dlang.org/post/ot1q8b$23pt$1@digitalmars.com
https://github.com/dlang/dmd/pull/7242

I think Razvan focused on other projects no one else bothered enough to write a DIP about this.

On Saturday, 16 June 2018 at 00:20:35 UTC, Seb wrote:
>
> So of course, people obviously like syntactic sugar, but the problem is that nowadays one needs a strong argument when trying to convince W&A for introducing yet another language feature as it bloats the language and makes it harder for newcomers to learn it and read code in it. Also in the past a few language features haven't turned out to be that great, so that's why nowadays there's more caution.


Is D trying to beat Python in learning as first language or what?
How for example ?. operator would make it harder to learn when one doesn't even use it in their code? Or string interpolation?
And when encountered in others people code this will raise questions "what is that fancy thing?", then knowing about such things would raise another question "this is definetely some nice feature, how can I use it to improve my own code?", and that's it, this is the point of no return, say goodbye to old ugly code. But right, D doesn't need that... of course D doesn't even needs working DLL's

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

On Saturday, 16 June 2018 at 02:44:04 UTC, Jonathan M Davis wrote:
>
> 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.

The main problem with library solutions is the fact that corresponding language services are not available for them (think of code completion). Even if a language service will make the effort to interpret a library construct like SafeAccess!stuff and provide code completion, it will not work for other names - maybe I'd like to use Elvis!stuff. On the contrary, if it's built in the language and the meaning of stuff? is guaranteed to be the same across compilers, the language services can safely assume it and provide all associated goodies.

The same problem is encountered with property bloat code, mixin constructs are not the best friends of language services.

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

On Saturday, 16 June 2018 at 05:48:26 UTC, Nick Sabalausky (Abscissa) wrote:
> 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.

Funny that you mention that. Back 6 years ago when I was looking for a C++ alternative that wasn't Java, and came across D (I think I saw it mentioned on Bartosz Milewski's site somewhere), there were exactly three things that took me from "okay, this is kind of cool" to "man, this looks awesome. I need to jump in and start learning this language right away":

Array slicing (no brainer)
Array operations (like a[] *= 3)
Built-in complex numbers

At the time though, I thought it was so cool that there was a language that had syntactic sugar like this (I was an undergrad student at the time, and I was getting really tired of having to write out for-loops in Java - never mind that I think Java had introduced for-each syntax at this point).

The fact that

for (int i = 0; i < array.length; i++)
{
    array[i] *= 3;
}

Could be replaced with a one-liner in D just blew my mind.

Same for complex numbers, I guess. I don't generally care about complex numbers and rarely use them, if ever, but I just thought it was so cool that having them built-in made the code so straightforward and beautiful.

>> * a good syntax for properties so there's less code bloat.
>
> That bugged me for awhile, too, due to my earlier C# experience...

I wrote a lot of C# a few years ago working on a big project for my then-employer, and I missed a lot of D features. However, the one thing I think I miss the most in D is C#'s getter/setter syntax. I hate using properties in D, because they are not transparently substitutable with bare members (even when we assume no static introspection), and because it requires two separate declarations to define both a setter and a getter function.

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

I do wish D had some sort of procedural macro system a la what they're trying to do in Rust. The template systems C++ and D have now are just clumsier macro systems with a fraction of the power and double the complexity.


At this point, it's a matter of taste, and Walter and Andrei's taste differs from mine. The only way I can truly get what I want from the D language is to fork it, which I don't have the time or knowledge to properly maintain. Maybe once I retire and get fed up with D, like Walter with C++, and thus the cycle begins anew ;-)