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
