Re: D community's view on syntactic sugar
On Saturday, 30 June 2018 at 15:08:52 UTC, Dmitry Olshansky wrote: On Saturday, 30 June 2018 at 13:12:44 UTC, Meta wrote: [...] Oh my... I don’t know *exactly* how it works(?) [...] You sir appeared to be drunk when typing this, because I have no idea what you are trying to say here.
Re: D community's view on syntactic sugar
On Saturday, 30 June 2018 at 15:08:52 UTC, Dmitry Olshansky wrote: On Saturday, 30 June 2018 at 13:12:44 UTC, Meta wrote: [...] Oh my... I don’t know *exactly* how it works(?) [...] I think someone needs to take away your metaphorical keys lol
Re: D community's view on syntactic sugar
On Saturday, 30 June 2018 at 15:08:52 UTC, Dmitry Olshansky wrote: On Saturday, 30 June 2018 at 13:12:44 UTC, Meta wrote: [...] Oh my... I don’t know *exactly* how it works(?) [...] If anyone figures out what this said I'd be interested.
Re: D community's view on syntactic sugar
On Saturday, 30 June 2018 at 09:34:30 UTC, Dmitry Olshansky wrote: Okay. I see that you see. I “meet” a guy, you know I admire that he _somehow_ made an HTTP Application server that is faster then let’s pick good stuff... Nginx Plus with tuning by Igor himeself (before sweat too mich like Igor at least twice did - no shit these discussion, you THAT guy he rans his... GWAN? as if it was _just_ an spplication server. You know not a word more but sombody who say: - knows infosecurity and likes that stuff that say slices into the kernel - rootkit for instance - aand say injects something into the kernel You know where it goes and yet that guy obviously good and the humor Boy wicked humor, I kid you not I “invented” this trick this morning AND *solved* the _mystery_ of GWAN. Fuck, it is at _very_ least a brilliant hoax, and boy he is good... He if that’s the real name I mean what if this is Linus (oh, my and you know GWAN started _as_ _windows_ “app server” ...) If you don’t laught now... I don’t now.. At the *very* least don’t _ever_ go to DConf... What the fuck with brain like you simply will not like it P.S. Atilla even if that is “alternative way” to *do* it... Yeah. Let’s say you owe... a bear and an a few hours to dicsuss it, okay? ;) I have no idea what I just read, but I'll have 10 of what you're having.
Re: D community's view on syntactic sugar
On Saturday, 30 June 2018 at 07:45:48 UTC, John Belmonte wrote: On Saturday, 16 June 2018 at 08:39:07 UTC, Dmitry Olshansky wrote: On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer wrote: T* he `async` & `await` keyword from C# make proactor pattern async code extremely easy to reason about. God please no. Look at Go’s popularity because of dead simple go routines and “async i/o is transparent and looks blocking but ain’t so”. We have at least vibe.d for that and possibly more. Also see Java doing fibers recently, and Kotlin did them just a year or so back. People love fibers and mostly dislike Futers/explicit async, and plain callbacks are obvious last resort that nobody likes. ‘async’ is viral keywords that poorly scales, I worked on Dart core team and even they admitted this problem is not solved well. I've found it fascinating to follow discussion and efforts to improve the structure and control of concurrency and async operations for software programming in general. I'm not partial to async/await at this time but it seems rash to discount it. Okay. I see that you see. I “meet” a guy, you know I admire that he _somehow_ made an HTTP Application server that is faster then let’s pick good stuff... Nginx Plus with tuning by Igor himeself (before sweat too mich like Igor at least twice did - no shit these discussion, you THAT guy he rans his... GWAN? as if it was _just_ an spplication server. You know not a word more but sombody who say: - knows infosecurity and likes that stuff that say slices into the kernel - rootkit for instance - aand say injects something into the kernel You know where it goes and yet that guy obviously good and the humor Boy wicked humor, I kid you not I “invented” this trick this morning AND *solved* the _mystery_ of GWAN. Fuck, it is at _very_ least a brilliant hoax, and boy he is good... He if that’s the real name I mean what if this is Linus (oh, my and you know GWAN started _as_ _windows_ “app server” ...) If you don’t laught now... I don’t now.. At the *very* least don’t _ever_ go to DConf... What the fuck with brain like you simply will not like it P.S. Atilla even if that is “alternative way” to *do* it... Yeah. Let’s say you owe... a bear and an a few hours to dicsuss it, okay? ;) Elsewhere in this thread, the "What Color is Your Function?" article was referenced against async/await. (http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/). There's a fair rebuttal to that article, "The Function Color Myth". (https://lukasa.co.uk/2016/07/The_Function_Colour_Myth/). I.e. all the concurrency models can be done without coloring. Coloring is an aid which can be used judiciously. There's the "Unyielding" article which argues that implicit coroutines are just as hard to reason about as preemptive threading. (https://glyph.twistedmatrix.com/2014/02/unyielding.html) Most promising in this area is a recent article by Nathaniel J Smith: "Notes on structured concurrency, or: Go statement considered harmful" (https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/) Essentially he's arguing that the way we spawn concurrent tasks is as bad as global goto/jump was in its day, and we need to reign in concurrency with some control structures which let us reason easily about task lifetimes, cleanup, error propagation, etc. His implementation of these ideas happens to be built on top of Python's async/await, but I don't think that primitive is a requirement. It would be interesting to try to implement these control structures by library in D, and perhaps it would suggest some primitives lacking from or better suited for the language itself. The fact that D hasn't yet jumped on either of the async/await or implicit coroutines bandwagons puts it in a good position to get this right.
Re: D community's view on syntactic sugar
On Saturday, 16 June 2018 at 08:39:07 UTC, Dmitry Olshansky wrote: On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer wrote: T* he `async` & `await` keyword from C# make proactor pattern async code extremely easy to reason about. God please no. Look at Go’s popularity because of dead simple go routines and “async i/o is transparent and looks blocking but ain’t so”. We have at least vibe.d for that and possibly more. Also see Java doing fibers recently, and Kotlin did them just a year or so back. People love fibers and mostly dislike Futers/explicit async, and plain callbacks are obvious last resort that nobody likes. ‘async’ is viral keywords that poorly scales, I worked on Dart core team and even they admitted this problem is not solved well. I've found it fascinating to follow discussion and efforts to improve the structure and control of concurrency and async operations for software programming in general. I'm not partial to async/await at this time but it seems rash to discount it. Elsewhere in this thread, the "What Color is Your Function?" article was referenced against async/await. (http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/). There's a fair rebuttal to that article, "The Function Color Myth". (https://lukasa.co.uk/2016/07/The_Function_Colour_Myth/). I.e. all the concurrency models can be done without coloring. Coloring is an aid which can be used judiciously. There's the "Unyielding" article which argues that implicit coroutines are just as hard to reason about as preemptive threading. (https://glyph.twistedmatrix.com/2014/02/unyielding.html) Most promising in this area is a recent article by Nathaniel J Smith: "Notes on structured concurrency, or: Go statement considered harmful" (https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/) Essentially he's arguing that the way we spawn concurrent tasks is as bad as global goto/jump was in its day, and we need to reign in concurrency with some control structures which let us reason easily about task lifetimes, cleanup, error propagation, etc. His implementation of these ideas happens to be built on top of Python's async/await, but I don't think that primitive is a requirement. It would be interesting to try to implement these control structures by library in D, and perhaps it would suggest some primitives lacking from or better suited for the language itself. The fact that D hasn't yet jumped on either of the async/await or implicit coroutines bandwagons puts it in a good position to get this right.
Re: D community's view on syntactic sugar
On 06/20/2018 05:44 PM, Kamil Koczurek wrote: On Saturday, 16 June 2018 at 02:44:04 UTC, Jonathan M Davis wrote: * 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. That's not the only use case. Recently I'm using Algebraic pretty often and I really wish that this would work: alg.peek!AThing?.method(); That is a good point, however, it could (and has been) be argued that Phobos's Algebraic is a sub-optimal design to begin with. For example, see these alternatives which cleanly eliminate the need for ".peek": https://github.com/s-ludwig/taggedalgebraic https://github.com/pbackus/sumtype Although, granted, there's still Variant... (But in any case, I'd still like to see null conditional operator in D anyway. It may not be applicable in a lot of idiomatic D code, but that doesn't mean it wouldn't be useful and worth having.)
Re: D community's view on syntactic sugar
On 06/16/2018 03:18 AM, Sjoerd Nijboer wrote: On Saturday, 16 June 2018 at 05:48:26 UTC, Nick Sabalausky (Abscissa) wrote: But short of that...no sugar is likely to happen anytime soon that isn't library-based, I'm genuinely sorry to report :( The reason I don't like library support in particular because you can't alway rely on a library, they take some time setting up, and maybe the open source project you're contributing to doesn't want libraries whatever how small. Sorry, I was unclear: I meant the standard library, not third party library. (Although, third party library is certainly always one way to go too.)
Re: D community's view on syntactic sugar
On Sunday, 17 June 2018 at 16:52:59 UTC, Neia Neutuladh wrote: I agree with you for the whole bunch. Except this one allocator.make!Foo(args) new!allocator Foo(args) One character difference. Doesn't seem like a big deal. new is a keyword in D right now which gcallocs an object and emplaces a T on top of it. make does thesame thing, but you can pass it any allocator you want. allocating and emplacing a type is so often done that you might want a keyword for it. Why not unify these two? Seems like there's now a duplicate way to do thesame thing in the language standard. Even worse, new has a strictly defined meaning accross a lot of languages, while make doesn't. Its just an oddity right now. But my biggest reason to unify it is to do something different, introducing a feature where one could get the allocator with which the current class has been instantiated, and allow the current class to allocate and conditional deallocate if neccesarily with that one. This would allow gc code to be @nogc depending on the used allocator. Overloading `new` for this, and retaining the default behaviour would allow current code to be relatively easily converted, and for gc allocator dependant libraries a calculated find and replace would allow conversion to different gc allocators... but that's a different story. (Mainly just an idealistic wish from me.) My main reason to start this threat was to see if there was spirit to add syntactic sugar as a language feature. And it quite provided in that goal. While adding sugar as libraries using mixins isn't my preference and as far as I think should be used as a last resort, it is something I haven't explored before. I also understand that some things aren't neccesarily good candidates of syntactic sugars, but these were some examples I could come up with quite easily at the time. All with all I like D and the community for the level of talk behind the language design. It is something I haven't seen before around a language quite like this. :)
Re: D community's view on syntactic sugar
On 2018-06-16 07:48, Nick Sabalausky (Abscissa) wrote: 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. A couple of years ago I started trying to implement AST macros [1], it's pretty stale now. [1] https://github.com/jacob-carlborg/dmd/tree/macro -- /Jacob Carlborg
Re: D community's view on syntactic sugar
On 2018-06-16 04:44, Jonathan M Davis wrote:
* 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.
There's code in the DMD front end which screams for this operator.
The AST is built out of classes. It uses virtual functions to do down
casting, i.e.
class Statement
{
ForStatement isForStatement()
{
return null;
}
}
class ForStatement : Statement
{
ForStatement isForStatement()
{
return null;
}
}
Statement s;
if (auto f = s.isForStatement) { f. ... }
--
/Jacob Carlborg
Re: D community's view on syntactic sugar
On Saturday, 16 June 2018 at 02:44:04 UTC, Jonathan M Davis wrote: * 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. That's not the only use case. Recently I'm using Algebraic pretty often and I really wish that this would work: alg.peek!AThing?.method();
Re: D community's view on syntactic sugar
On Monday, 18 June 2018 at 20:54:22 UTC, aberba wrote: async/await make asynchronous code in C# and JavaScript look clean and easy to wrap ones head around it. Solution to aka. callback hell. If popularity is what you're looking at, it JavaScript not Go. And async/await is all over the place...it more that a syntactic sugar, it a pattern. Threads make it easy to write code that does long-running things like IO without blocking your process. Continuation-passing style is an answer to your platform not having threads. Async/await is an answer to the problems of heavily nested scopes and awkward error handling in the continuation-passing style. D has threads. The one uncommon case that suffers here is starting operations in parallel and collecting their results afterwards. I believe Vibe has an implementation of futures and a convenience function to run code in a separate thread and get a Future holding the result. This does hold up one thread waiting for the others to complete, which is mildly suboptimal, but you can solve that as well as async/await by arbitrarily picking one long-running operation to execute in the current thread. ‘async’ is viral keywords that poorly scales, I worked on Dart core team and even they admitted this problem is not solved well. Doesn't scales for what? You generally can't call an async function from a non-async function, and you need some extra dressing on an async function call. (In C# you can manually get the Task<> back and use that, but that's painful.) So you use all async IO. You write a function. It works in memory and doesn't do IO, so you make it easy to call: you make it a sync function. Then you change it, and now it does IO. (Maybe it checks values from a config file, and you change it to check if the config file changed on disk.) Now you have to mark the function async and change every call site to add the await keyword. Except some of these functions might not have been async already. So you have to mark them async and repeat the process across your whole codebase. You could make everything async by default, but then calling functions is harder. Only a little, but calling functions is probably like 20% of my expressions, and I could do without the syntactic bitter yuck.
Re: D community's view on syntactic sugar
On Tuesday, 19 June 2018 at 07:14:11 UTC, Dmitry Olshansky wrote: On Monday, 18 June 2018 at 20:54:22 UTC, aberba wrote: On Saturday, 16 June 2018 at 08:39:07 UTC, Dmitry Olshansky 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. Oh kid. I tried all of that and more. Like 4 years ago. Pardon for my temper but no I know what I’m talking about and it’s not “I tried it for a week and now I see async is nice”. To hell with that! I have actually seen and worked (not directly) on code **cking does make async stack traces tolerable (google for causal stack traces, Dart). Again sorry to hurt your feelings but unless I see deep technical good reason to go for async, I’ll die fighting against it. Let’s bot cargocult for once, especially considering the interplay with just about any bloody language feature to get “shugar”. P.S. Damn, it really pusses me off. No offence was meant. No offense taken. I feel your rage...ha ha. What happened between you and the past where JavaScript was involved? — Dmitry Olshansky
Re: D community's view on syntactic sugar
On Tuesday, 19 June 2018 at 13:39:51 UTC, 12345swordy wrote: On Tuesday, 19 June 2018 at 07:14:11 UTC, Dmitry Olshansky wrote: To hell with that! I have actually seen and worked (not directly) on code **cking does make async stack traces tolerable (google for causal stack traces, Dart). Again sorry to hurt your feelings but unless I see deep technical good reason to go for async, I’ll die fighting against it. Let’s bot cargocult for once, especially considering the interplay with just about any bloody language feature to get “shugar”. P.S. Damn, it really pusses me off. No offence was meant. — Dmitry Olshansky Yesh. To me, it sounds like you had to work with a bunch of bad programmers rather than the faults with async. Not a single thing I said had to do with people except me describing how JS (probably) came to intriduce async. To put specifically: no my argument is completly orthogonal to that. I hope you can see it after a while. Alexander
Re: D community's view on syntactic sugar
On Tuesday, 19 June 2018 at 07:14:11 UTC, Dmitry Olshansky wrote: To hell with that! I have actually seen and worked (not directly) on code **cking does make async stack traces tolerable (google for causal stack traces, Dart). Again sorry to hurt your feelings but unless I see deep technical good reason to go for async, I’ll die fighting against it. Let’s bot cargocult for once, especially considering the interplay with just about any bloody language feature to get “shugar”. P.S. Damn, it really pusses me off. No offence was meant. — Dmitry Olshansky Yesh. To me, it sounds like you had to work with a bunch of bad programmers rather than the faults with async. Alexander
Re: D community's view on syntactic sugar
On Tuesday, 19 June 2018 at 07:14:11 UTC, Dmitry Olshansky wrote: On Monday, 18 June 2018 at 20:54:22 UTC, aberba wrote: [...] I look at popularity but I prefer crutical thinking. Nothing beats simple non-async code in understamdability save for declarative stuff or no code. Really no code is best but obviously not always an option. [...] I hear your rage. People should not sip the kool aid lightly. Avoid *ANY* form of complexity unless it is really needed. Add code only when needed Keep things synchronous until you cannot then redesign so you can If you really really must use asynchronous design know why you must and what you are getting into then decouple that code as much as possible.
Re: D community's view on syntactic sugar
On Monday, 18 June 2018 at 20:54:22 UTC, aberba wrote: On Saturday, 16 June 2018 at 08:39:07 UTC, Dmitry Olshansky 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. T* he `async` & `await` keyword from C# make proactor pattern async code extremely easy to reason about. God please no. Look at Go’s popularity because of dead simple go routines and “async i/o is transparent and looks blocking but ain’t so”. We have at least vibe.d for that and possibly more. Also see Java doing fibers recently, and Kotlin did them just a year or so back. People love fibers and mostly dislike Futers/explicit async, and plain callbacks are obvious last resort that nobody likes. async/await make asynchronous code in C# and JavaScript look clean and easy to wrap ones head around it. Solution to aka. callback hell. If popularity is what you're looking at, it JavaScript not Go. And async/await is all over the place...it more that a syntactic sugar, it a pattern. I look at popularity but I prefer crutical thinking. Nothing beats simple non-async code in understamdability save for declarative stuff or no code. Really no code is best but obviously not always an option. So why async in JS? That is because it’s their last choice to make things at least _look_ better. To give you a picture of how JS got to async you have to understand that they started (and still in many ways are) as Practically all of today’s JS execution environments are single threaded process with integrated eventloop for events such as timers and clicks. They introduced APIs back in 199x that used callbacks exclusively. Then people constructed Futures (Deferred etc.) on top. But it’s a JavaScript (popular, just like you said) so it has to make it more builtin and simple. Because *some* (many) would think that say jQuery Deffered is slow, you’d better use plain callbacks. All of that stupidity sqaured is a day in day out talk in JS world, because well popularity. So being wise they decided to not destroy the excecution model (but extend with workers, which are isolated process btw) but cheaply extend it with syntax shugar. And they succeeded because now you come and say that’s basically the best thing to do. It is not though, and I believe I’ve seen enough to act against it. I use Scala everyday, and there Futures and Monads all the way down in I/O, and no it’s not simpler nor faster model. It’s okayish but that’s about it. Compared to proper scheduler with integrated eventloop: async is not fast - same as futures, could use a bit less RAM per connection etc., but same or worse speed (and if you need say.. stacktrace;)) async is not convenient because it splits functions into “red” and “green”, and you can mix them anymore async is best effort attempt to make imperatice programmers write future-based, monadic code (essentially). It was great success in that, but no, please let’s pick the better model (in general, ofc, special needs are special). ‘async’ is viral keywords that poorly scales, I worked on Dart core team and even they admitted this problem is not solved well. Doesn't scales for what? Try C# or JavaScript and experience the true power of async/await. Oh kid. I tried all of that and more. Like 4 years ago. Pardon for my temper but no I know what I’m talking about and it’s not “I tried it for a week and now I see async is nice”. To hell with that! I have actually seen and worked (not directly) on code **cking does make async stack traces tolerable (google for causal stack traces, Dart). Again sorry to hurt your feelings but unless I see deep technical good reason to go for async, I’ll die fighting against it. Let’s bot cargocult for once, especially considering the interplay with just about any bloody language feature to get “shugar”. P.S. Damn, it really pusses me off. No offence was meant. — Dmitry Olshansky
Re: D community's view on syntactic sugar
On Saturday, 16 June 2018 at 08:39:07 UTC, Dmitry Olshansky 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. T* he `async` & `await` keyword from C# make proactor pattern async code extremely easy to reason about. God please no. Look at Go’s popularity because of dead simple go routines and “async i/o is transparent and looks blocking but ain’t so”. We have at least vibe.d for that and possibly more. Also see Java doing fibers recently, and Kotlin did them just a year or so back. People love fibers and mostly dislike Futers/explicit async, and plain callbacks are obvious last resort that nobody likes. async/await make asynchronous code in C# and JavaScript look clean and easy to wrap ones head around it. Solution to aka. callback hell. If popularity is what you're looking at, it JavaScript not Go. And async/await is all over the place...it more that a syntactic sugar, it a pattern. ‘async’ is viral keywords that poorly scales, I worked on Dart core team and even they admitted this problem is not solved well. Doesn't scales for what? Try C# or JavaScript and experience the true power of async/await.
Re: D community's view on syntactic sugar
On Monday, 18 June 2018 at 01:06:48 UTC, evilrat wrote:
On Sunday, 17 June 2018 at 17:48:21 UTC, FromAnotherPlanet
wrote:
On Sunday, 17 June 2018 at 16:52:59 UTC, Neia Neutuladh wrote:
The only case where D loses out is compared to { get; private
set; }.
That's a pretty big thing to give up. That allows for pretty
valuable control over visibility of encapsulated properties.
He means that in D this is split like that, which isn't as
clean as C# does
class MyClass
{
private int _myProp; // backing field
private @property void myProp(int a) { _myProp = a; } //
private setter
public @property int myProp() { return _myProp; } // getter
}
Well the cool part about D is that we can generate such sugar
without necessarily needing to have it in the language (though a
better property syntax would be great).
Anyhow here's an example from the accessors package
(https://github.com/funkwerk/accessors):
import accessors;
class WithAccessors
{
@Read @Write
private int num_;
// list all your fields here
mixin(GenerateFieldAccessors);
}
Re: D community's view on syntactic sugar
On Sunday, 17 June 2018 at 17:48:21 UTC, FromAnotherPlanet wrote:
On Sunday, 17 June 2018 at 16:52:59 UTC, Neia Neutuladh wrote:
The only case where D loses out is compared to { get; private
set; }.
That's a pretty big thing to give up. That allows for pretty
valuable control over visibility of encapsulated properties.
He means that in D this is split like that, which isn't as clean
as C# does
class MyClass
{
private int _myProp; // backing field
private @property void myProp(int a) { _myProp = a; } //
private setter
public @property int myProp() { return _myProp; } // getter
}
Re: D community's view on syntactic sugar
On Sunday, 17 June 2018 at 16:52:59 UTC, Neia Neutuladh wrote:
The only case where D loses out is compared to { get; private
set; }.
That's a pretty big thing to give up. That allows for pretty
valuable control over visibility of encapsulated properties.
Re: D community's view on syntactic sugar
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 `?.`
Null-safe dereference operator, I think it's called?
Hrm, my first impulse was in favor. I find this useful in Kotlin
and I miss it when using Java. In D, I don't encounter null very
often at all.
* Something like a `yield return` statement for coroutines.
For iterables, more like? If you want a userspace thread, Fiber
gives you this. But it can be annoying right now to write a range.
T* he `async` & `await` keyword from C# make proactor pattern
async code extremely easy to reason about.
http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/
Maybe not the best. It's useful when you want to execute a small
fixed number of heterogeneous things in parallel, but the cost is
that everyone has to choose whether to make their thing run
asynchronously or synchronously, and there's going to be pressure
to make everything that could take more than a few milliseconds
to go asynchronous. This would force almost every program to be
multithreaded.
* a good syntax for properties so there's less code bloat.
C# has syntax like:
public int Something { get; set; }
It does this to make it easier to switch out a field for a
computed property, to add validation to a field, and to let you
put properties into interfaces.
D code typically doesn't use interfaces much, and you don't have
to do anything special to convert a field into a getter/setter
pair.
The only case where D loses out is compared to { get; private
set; }.
* 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?
allocator.make!Foo(args)
new!allocator Foo(args)
One character difference. Doesn't seem like a big deal.
Re: D community's view on syntactic sugar
On Saturday, 16 June 2018 at 18:49:43 UTC, Steven Schveighoffer wrote: On 6/15/18 8:53 PM, Seb wrote: On Saturday, 16 June 2018 at 00:32:24 UTC, H. S. Teoh wrote: On Sat, Jun 16, 2018 at 12:20:35AM +, 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. I don't know if this is the same thing. I'm not a (recent) C# developer, but in Swift, ?. means something completely different from ?: in Andrei's proposal. -Steve Yes, Andrei's proposal was for the equivalent of ?? in C#. int* p = null; int n = p ?: 42; assert(n == 42);
Re: D community's view on syntactic sugar
On 6/15/18 8:53 PM, Seb wrote: On Saturday, 16 June 2018 at 00:32:24 UTC, H. S. Teoh wrote: On Sat, Jun 16, 2018 at 12:20:35AM +, 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. I don't know if this is the same thing. I'm not a (recent) C# developer, but in Swift, ?. means something completely different from ?: in Andrei's proposal. -Steve
Re: D community's view on syntactic sugar
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. First of all, it’s not missing but deliberately not added for many reason, which I’m sure other folks from core team will provide and correct me where applicable. * The null conditional operator `?.` Might be interesting but we need to try more principled approach alng the line of Option!T type with nice accessors and maybe even make non-null a default. The latter will take not a single year though. But peppering language with more built-in magic is not our direction, I’m pretty certain of that. * Something like a `yield return` statement for coroutines. That was on the radar actually, and would encode stackless automation wrapped as InputRange. Problem is how to get it to be say forward range (i.e. state saving would really be nice to include). For stackfull we have std.concurrency.Generator in library code just fine (IIRC). T* he `async` & `await` keyword from C# make proactor pattern async code extremely easy to reason about. God please no. Look at Go’s popularity because of dead simple go routines and “async i/o is transparent and looks blocking but ain’t so”. We have at least vibe.d for that and possibly more. Also see Java doing fibers recently, and Kotlin did them just a year or so back. People love fibers and mostly dislike Futers/explicit async, and plain callbacks are obvious last resort that nobody likes. ‘async’ is viral keywords that poorly scales, I worked on Dart core team and even they admitted this problem is not solved well. * 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? Is a good idea, but syntactic sugar is smallest part of this problem if at all. 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. Yeah it won’t be smooth then I could see. 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.
Re: D community's view on syntactic sugar
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"
Re: D community's view on syntactic sugar
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 `?.` Yeah, me too. I have to say that at least D is expressive enough to allow the safeAccess template, as mentioned before, although there are several drawbacks: it's in many cases sub-optimal, it's not autocompletion-friendly at all, it's less distinguishable from an operator. But well, really it's nice that it's possible as a template. No need to harass the language leaders for that.
Re: D community's view on syntactic sugar
On Saturday, 16 June 2018 at 05:48:26 UTC, Nick Sabalausky (Abscissa) wrote: But short of that...no sugar is likely to happen anytime soon that isn't library-based, I'm genuinely sorry to report :( Most of these just seem like an easy win on the attractiveness of D. Big benefits of language based sugar is good tooling and debugging support. Not only would that make the language more attractive to outsiders who did have those things in other languages and refuse to use D whitout, but if properly implemented limit the strain on the brain of the programmer which opens up D to a new set of programmers. The reason I don't like library support in particular because you can't alway rely on a library, they take some time setting up, and maybe the open source project you're contributing to doesn't want libraries whatever how small. When people do use a library there is always licencing to think about and maybe, just maybe they chose a library you're already familiar with and you won't have to re-learn known concepts from a different library. (This last one is a real dealbreaker for me) Maybe in time, if a particular library is proven to be superior over existing syntax it'll get language support. But with the mantra "fast code, fast" I'm frankly kind of disappointed that such desicions weren't done before. I realize I missed out on some very usefull libraries and I'll look in to them and most likely start using them, but untill most of these things are implemented I still have this sour feeling in my mouth. Maybe some syntactic sugar will solve that. :P
Re: D community's view on syntactic sugar
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
;-)
Re: D community's view on syntactic sugar
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 S 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 s 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
propertywhatever...")
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,
Re: D community's view on syntactic sugar
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.
Re: D community's view on syntactic sugar
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
Re: D community's view on syntactic sugar
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 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
Re: D community's view on syntactic sugar
On Saturday, 16 June 2018 at 00:32:24 UTC, H. S. Teoh wrote: On Sat, Jun 16, 2018 at 12:20:35AM +, 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.
Re: D community's view on syntactic sugar
On Sat, Jun 16, 2018 at 12:20:35AM +, 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!
Re: D community's view on syntactic sugar
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 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)
Re: D community's view on syntactic sugar
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.
