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