www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D community's view on syntactic sugar

reply Sjoerd Nijboer <sjoerdnijboer gmail.com> writes:

simple syntactic sugar missing from D.

* The null conditional operator `?.`
* Something like a `yield return` statement for coroutines.

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 

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.
Jun 15 2018
next sibling parent DigitalDesigns <DigitalDesigns gmail.com> writes:
On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer wrote:

 simple syntactic sugar missing from D.

 * The null conditional operator `?.`
 * Something like a `yield return` statement for coroutines.

 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 

 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.
Jun 15 2018
prev sibling next sibling parent reply Seb <seb wilzba.ch> writes:
On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer wrote:

 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

 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 

 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)
Jun 15 2018
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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:

 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!
Jun 15 2018
parent reply Seb <seb wilzba.ch> writes:
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:

 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.
Jun 15 2018
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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 +0000, Seb via Digitalmars-d wrote:
 On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer wrote:

simple syntactic sugar missing from D.
 * The null conditional operator `?.`
e.g. SafeAccess https://github.com/BBasile/iz/blob/7336525992cb178ead83a7893a5a54597d840441/imp rt/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.
but in Swift, ?. means something completely different from ?: in Andrei's proposal. -Steve
Jun 16 2018
parent Meta <jared771 gmail.com> writes:
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 +0000, Seb via 
 Digitalmars-d wrote:
 On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer 
 wrote:

 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.
developer, but in Swift, ?. means something completely different from ?: in Andrei's proposal. -Steve
int* p = null; int n = p ?: 42; assert(n == 42);
Jun 16 2018
prev sibling parent evilrat <evilrat666 gmail.com> writes:
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
Jun 15 2018
prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, June 15, 2018 23:04:40 Sjoerd Nijboer via Digitalmars-d wrote:

 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 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 the same thing if you really want a short-hand way to do it.
 * Something like a `yield return` statement for coroutines.

 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

 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
Jun 15 2018
next sibling parent rumbu <rumbu rumbu.ro> writes:
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.
Jun 15 2018
prev sibling next sibling parent reply Kamil Koczurek <koczurekk gmail.com> writes:
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 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 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();
Jun 20 2018
parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
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 especially with range-based programming. That's not to say that certain types of programs couldn't benefit from such syntax, but it's 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.)
Jun 22 2018
prev sibling parent Jacob Carlborg <doob me.com> writes:
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 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 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
Jun 21 2018
prev sibling next sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 06/15/2018 07:04 PM, Sjoerd Nijboer wrote:

 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 .NET 3 or 4 IIRC), and as much as I love D, this is the one thing from 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... ;)

 extremely easy to reason about.
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). 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.
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. *are* something you can get used to. (And TBH, in D, I would simply 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 

 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.
low-level features and metaprogramming made me feel *far* less constrained overall), I really, really, really do wish that D still 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 :(
Jun 15 2018
next sibling parent Meta <jared771 gmail.com> writes:
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.
experience...
my then-employer, and I missed a lot of D features. However, the 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 ;-)
Jun 15 2018
prev sibling next sibling parent reply Sjoerd Nijboer <sjoerdnijboer gmail.com> writes:
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
Jun 16 2018
parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
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.)
Jun 22 2018
prev sibling parent Jacob Carlborg <doob me.com> writes:
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
Jun 21 2018
prev sibling next sibling parent Basile B. <b2.b2.b2.temp.temp gmx.gmx.com.com> writes:
On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer wrote:

 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.
Jun 16 2018
prev sibling next sibling parent Bauss <jj_1337 live.dk> writes:
On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer wrote:

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

 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"
Jun 16 2018
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer wrote:

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

 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 

Yeah it won’t be smooth then I could see.

 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.
Jun 16 2018
next sibling parent reply aberba <karabutaworld gmail.com> writes:
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:

 seemingly simple syntactic sugar missing from D.

 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.
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?
Jun 18 2018
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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:

 seemingly simple syntactic sugar missing from D.

 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.
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? 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
Jun 19 2018
next sibling parent Norm <norm.rowtree gmail.com> writes:
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.
Jun 19 2018
prev sibling next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
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
Jun 19 2018
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Jun 19 2018
prev sibling parent aberba <karabutaworld gmail.com> writes:
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:

 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
Jun 19 2018
prev sibling parent Neia Neutuladh <neia ikeran.org> writes:
On Monday, 18 June 2018 at 20:54:22 UTC, aberba wrote:

 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 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.
Jun 19 2018
prev sibling parent reply John Belmonte <john neggie.net> writes:
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:

 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.
Jun 30 2018
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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:

 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.
Jun 30 2018
parent reply Meta <jared771 gmail.com> writes:
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.
Jun 30 2018
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Saturday, 30 June 2018 at 13:12:44 UTC, Meta wrote:
 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.
Oh my... I don’t know *exactly* how it works(?) I mean what the fact let’s start with I don’t what to use... boy want and we need something good!!! And yes that secret you since in such mood Let me try like I don’t .. Atilla fuck he must have seen but you CISCO!!! Simple words that... you know... Ask him about... CERN!!! Fuck that is if I’m jesus boooy that is dangeruos... like how do get okay Let’s lets say I didn’t because(in fact!!!!) I disn’t ... I mean where that fucking rocket science!!! You want humor? Think you are good? LET FUCKING HIT THAT... WHAT WAS I DON’t ... yet We are engineer ... fuck I know TCP I don’t mabye 98% I know it yes, I do but TCP. FUCK! Ask that cisco guy... Oh ... ehm. Atilla Neves, fuck nake thaf fucking typo? Will he let’s _play_ you see what I you I even beilive now even fuck THAT Okay real fact I travel FUCK do you I don’t I travel across Moscow to my place... And I can tell this trip, well not single too is the same I mean the let’s revers thst you when revers stuff it help or I don’t eventually does but differently You all see and you know it’s even hard! You like 4 words and you fuck if you sre not sinor just phone me!! Well if I do not pick up call that I don’t *know* (yeah that *will*) be epic(!) say that Tonkov guy. I mean yeeees style is everywher and if fucking can joke I give not grenade.. Take Atilla becase (fuuck!!!) now ... I try oh boy it is and happens if I don’t I just keep type... That 10 $ and there really no way back do I don’t think that opencollective .... boy Rust people samn please download that compiler fuck any of.. SUPPORT THIS JOKE... In the worst case like we in D (!!!!!!!!) Didn’t I ... the forums like work.. with Vladimir (oh my... !!) You I just mrntion Linus Torvald and why the fack not I run Ubuntu damn it’s hard fuck... I CANNOT GO BACK BUT IT IS ... ... .. Did I help D language?;) — Or you know fuck!!!! THAT MUST BE TRUE!!! Do you let me *tease* because even though I sent mail but fuck talked to him and boy he is good (since fuck I need to stop it is TRUEE!!!) Fuck I can damn I once I’m at work..... FUCK ... This I don’t how do you *think* Say Haven exists? Am I hear (fuck! No shit Atila, Andrei I _swear_ oh my what’s hard and copy I din’t that (again very true ... lots of people *do_ think that even typos make only bettee but car I will stop (somehow! You it’s a and ... mm it stops!!!) Okay I *might* fuck I will at least I dunno mail all .. Like do like my email, BUT I NEED TO PROVE THE POINT OKAY I’m oncincible say fuck if I joke like give at least 50% it’s good even in 1% what bad comes from 1%(!!!!! Yes that fuck expontent... self recursion THAT IS SELF RECURSIIOON) FUUUUUCKK THIS I HAVE EVEN SHOW TOU FUCK DLANG HOME PAGE AND THAT’s Stay simple humor is good that I think is hard to debat you like ask Linus but like when he is mot in rage (Intell... weel 2 or 3 words.. OK DO I HAVE TO TELL YOU (LOOK UP this bou))) It’s even simple!!! Fuck 10$ ... damn I have blood if some is human in me that is *say* my blood boooy. May I a CTO title (no money, where do I _think_ it can move you know YEEEES Popularity I solve say ... trolls inthe forums? And that VSCode money is here 645$ smth os there is it real? Andersi you how _flooows_ and boy I have even recalled ... shit inteview and surpies(!!!) boy C++ but let’s spin even this this a how... Boy Herb Sutter .. C++03 .... ... ... 8 smth is beeeest you know what I am doing like fir real, okay?? ... C++11 I had because you we luck... oh mu let’s do things proprly shall we .. Moscow DConf 2019 let’s _at least_ assume I mean he is a good you know “has” digital Bank... If that is not invincible and then fuck show that .. You cosck fuck typi.. Okay then just copy pate my work sometimes just a bit even if (!) I say _potentialy_ you it simple fuck can write program just post stuff it eill be and money women... heck gays I don’t we will not beat you... *at least* Really it is simple 2 hours, I don’t plaining but you in realliry I .. have wrote stairs Sriats Fuck I wrote see that that is power of D PROGRAMMING LANGUAGE MY WEBISTE FUCK WHERE I WAS THE LAST DCONF 2018 BOY WVERBODY WILL LIKE US OR WE BUY BEAR I DON’t Know Limit Wheresjv
Jun 30 2018
next sibling parent RealDUserTrump <down2now yahoo.com> writes:
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.
Jun 30 2018
prev sibling next sibling parent Chris M. <chrismohrfeld comcast.net> writes:
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
Jun 30 2018
prev sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
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.
Jun 30 2018
prev sibling parent reply Neia Neutuladh <neia ikeran.org> writes:
On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer wrote:

 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.

 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.
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.
Jun 17 2018
next sibling parent reply FromAnotherPlanet <fromanotherplanet fromanotherplanet.com> writes:
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.
Jun 17 2018
parent reply evilrat <evilrat666 gmail.com> writes:
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 class MyClass { private int _myProp; // backing field private property void myProp(int a) { _myProp = a; } // private setter public property int myProp() { return _myProp; } // getter }
Jun 17 2018
parent Seb <seb wilzba.ch> writes:
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 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); }
Jun 18 2018
prev sibling parent Sjoerd Nijboer <sjoerdnijboer gmail.com> writes:
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. :)
Jun 21 2018