On Friday, 20 October 2017 at 20:11:46 UTC, jmh530 wrote:
> On Friday, 20 October 2017 at 19:54:09 UTC, user1234 wrote:
>> On Friday, 20 October 2017 at 18:11:50 UTC, Adam D. Ruppe wrote:
>>> [...] The elvis operator, while trivial and
>>> unnecessary, would be easy to implement correctly and give
>>> a nice little PR boost to show that we care about the people
>>> talking about it.
>>
>> If you go by there, the safe navigation operator would probably even easier to implement than the elvis one.
>
> How about somebody implements the functionality, such as with what H.S. Teoh describes, and gets it added into phobos, maybe std.typecons b/c that's where nullable is?

No. Because of completion. Completion has to work after "?.", it's a postfix like the "." for aggregate members.

I can already tell that i wouldn't widely use a library solution.

On 10/20/17 04:04, Jonathan M Davis wrote:
> On Friday, October 20, 2017 02:49:34 Adam Wilson via Digitalmars-d wrote:
>> Here is the thing that bothers me about that stance. You are correct,
>> but I don't think you've considered the logical conclusion of the
>> direction your argument is headed. Pray tell, why must we stop adding
>> syntactic sugar? Why does their need to be an (by your own admission)
>> arbitrary limit?
>>
>> If we look at any moderately successful language
>> (C++/C#/Java/Python/etc.) you will find that all of them have
>> accumulated syntax sugar over the years at a fairly constant rate. For
>> example, C# has added point releases to it's release schedule for which
>> the express purpose is adding syntax sugar.
>
> It simply doesn't make sense to add every stray feature that folks ask for.
> Maybe some additional syntactic sugar will be added to D in the future, but
> there are way too many feature requests for it to make sense to implement
> even a small fraction of them. Some things are worth adding, but many really
> aren't. We have to say no frequently, or we'll be drowned in stray features
> to implement. And only so much can be added to a language before it becomes
> completely unwieldy. For instance, how many people are actually experts on
> C++ and understand all of its ins and outs? _Very_ few people. It's simply
> too complicated a language. Other languages aren't necessarily as bad off in
> that regard, but if you add enough to any language, it will get there. Every
> time you add something to the language, you stand the chance of improving
> some aspect of the language, but it comes at the cost of additional
> complexity. Sometimes the addition is worth that complexity, and sometimes
> it isn't.
>
> Knowing when to add something and when not to is often a tough question, but
> it's still true that you can't add everything. And inevitably, some of the
> things you leave out will annoy some people by their absence, just as some
> of the things you add will annoy some folks by being there.
>
> For better or worse, Walter and Andrei's current stance is essentially that
> if something can be reasonably done already in the language as it is,
> they're not adding a feature to do it. D is already insanely powerful as it
> is, and too often folks are looking to add a feature to the language when
> it's trivial to do it with a library solution. That certainly doesn't mean
> that nothing new is going to be added, but we have far more important
> features to worry about than saving someone from having to type a few extra
> characters because they want to use a couple of ?'s instead of typing out
> the code themselves or using a function call to encapsulate the behavior -
> e.g. finishing sorting out stuff like scope, @safety, and shared are far
> more critical.
>
> If someone has a really strong argument for why something is worth adding,
> then they're free to create a DIP for it, and if they can convince Walter
> and Andrei, it can make it into the language. But at this point in D's
> development, syntactic sugar really isn't high on the list of things that
> they consider to be of value. That doesn't mean that they're always right,
> but on the whole, I agree with them.
>
> - Jonathan M Davis
>

I never said "every stray feature" should be added. What I said is that "common idioms" should be added. Preferably without having to perform herculean feats of persuasion. And let's be honest, as a community we have a pretty good handle on what the common idioms are, seeing as how books have been written on the subject.

For example, ?? and ?. are ridiculously common idioms that we all perform every day in our D code. And as Mr. Ruppe rightly pointed out, it'd probably take about an hour each to knock together a complete PR for these features. But we have spent years arguing over because somebody at the top said "no more syntax sugar". Grammandos *adore* these types of proclamations because they give grammandos a line in the sand that they can defend at all costs. For example, in the US, we are taught that "ain't" is not an English word and should never be used. However, it has a long and storied history as an English word and has a specific use. But grammandos took their grammar teachers word as iron-clad law and have enforced it mercilessly, resulting in the death of a legitimate word. All because some British royalty didn't like it when the peasants started using the word 200 years ago.

So far I have seen three arguments proffered for the ban syntax sugar.

The first is "Walter/Andrei doesn't have the time." This is prima facie ridiculous as it presumes that Walter/Andrei must be the one to implement it. If this is the case then D dies in the same moment that Walter/Andrei does. Since that is obviously not the case, this argument can be safely invalidated by simply observing the environment in which D is created.

Every time I talk to Walter in-person about these sorts of proclamations he routinely says something along the lines of "It means that I won't be doing the work, but if someone wants to shepherd it through the PR process I'd gladly accept it." This position is quite rational, Walter's job is to focus on the big problems of D, not adding syntax sugar. I know this because I've specifically asked Walter about ?? and ?. in the past and his response was "So go do it. I'll accept it."

However, I think we've mistaken "I won't do it" for "It shall not be done." I say this because when these features do occasionally show up as PR's they are roundly criticized by the community grammandos for violating the Most Holy Laws of D. The PR author gives up, closes the PR, and Walter never has the chance to accept it.

Indeed, I don't contribute to D because I have little interest in doing the required verbal judo with the community grammandos. If I absolutely had too, I would open a PR and email Walter directly so that he could intervene directly before the grammandos can react. What I would NOT do is talk about it on the forums until AFTER Walter had approved it. But I have the advantage of being able to leverage a personal relationship. Our newcomers do not.

The second argument is "the language is already powerful enough to let you do that." This argument is specious. Yes, the language is powerful enough to do those things without syntax sugar. But syntax sugar isn't about power, it's about efficiency. So I certainly can write a function that does what ?. does but as we've already seen in this thread, there are multiple ways to name it. So far I've seen orElse and getOr. This creates a dialectic friction, whereby when moving to a new codebase I have to learn these new shibboleths. Those methods may function identically or they may have frustratingly subtle differences in implementation, and I have absolutely no way to know from reading the calling code.

By adding syntax sugar we standardize these idiomatic shibboleths. This improves the overall code read/write efficiency by standardizing both the language construct and the implementation of the idiom. Of course you are still free to write the non-idiomatic methods you need. And indeed, by standardizing the common idiom, it becomes trivial to differentiate the standard idioms from the non-standard idioms. This is a two-stage win for the language.

The third argument is: "syntax sugar makes the language more complicated." Again, specious. The correct answer is that the bad design and implementation of any language feature makes the language more complicated. A well done syntax sugar design and implementation significantly reduces code complexity for reasons stated in the second point.

D suffers from poorly designed and implemented features, which, in order to use successfully, require a significant amount of "deep knowledge" or knowledge that goes beyond what is shown in the code. That deep knowledge turns what should be a straight forward feature, @nogc for example, into book of unwritten knowledge about which language+library features allocate behind the scenes.

Much of the design of these syntax sugars has already been done for us. We know how async/await is supposed to function. We know how ?? and ?. function. We also know that most of these sugars vastly reduce complexity (and errors resulting from said complexity) because they've been proven to do just than in other languages for many years (decades in some cases). Async/Await is the perfect example of sugar that eliminated entire classes of threading related errors due to reduced implementation complexity.

Of course, you CAN implement Async methods in C# without Async/Await. C# is also powerful language with all the primitive tools required to do so. Indeed the compiler rewrites the await to IL that uses those tools. But why on earth would you? The code can be over 100 lines long per await and you will get something wrong.

Syntax sugar is a key component of any Safe language.

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

On Friday, 20 October 2017 at 22:25:20 UTC, Adam Wilson wrote:
> On 10/20/17 04:04, Jonathan M Davis wrote:
>> On Friday, October 20, 2017 02:49:34 Adam Wilson via Digitalmars-d wrote:

Preach

On Friday, October 20, 2017 15:25:20 Adam Wilson via Digitalmars-d wrote:
> So far I have seen three arguments proffered for the ban syntax sugar.
>
> The first is "Walter/Andrei doesn't have the time."

That actually has pretty much nothing to do with a feature request like syntactic sugar - especially if it's trivial to implement. Andrei in particular seems to feel strongly at this point that if something can be reasonably done with how the language is right now, then we don't need to add a feature for it. And if that's the case, then syntactic sugar stands pretty much no chance of getting in regardless of how easy it is to add. He even had some _removed_ after the work had already been done and merged - specifically using [$] in a static array declaration to infer the type, which we can't even fully do with a library right now thanks to https://issues.dlang.org/show_bug.cgi?id=16779.

> The second argument is "the language is already powerful enough to let you do that." This argument is specious. Yes, the language is powerful enough to do those things without syntax sugar. But syntax sugar isn't about power, it's about efficiency. So I certainly can write a function that does what ?. does but as we've already seen in this thread, there are multiple ways to name it. So far I've seen orElse and getOr. This creates a dialectic friction, whereby when moving to a new codebase I have to learn these new shibboleths. Those methods may function identically or they may have frustratingly subtle differences in implementation, and I have absolutely no way to know from reading the calling code.
>
> By adding syntax sugar we standardize these idiomatic shibboleths. This improves the overall code read/write efficiency by standardizing both the language construct and the implementation of the idiom. Of course you are still free to write the non-idiomatic methods you need. And indeed, by standardizing the common idiom, it becomes trivial to differentiate the standard idioms from the non-standard idioms. This is a two-stage win for the language.

Well, I think that you'd need to prove that the syntactic sugar objectively improved a lot of existing D code to stand much chance of convincing Andrei. My guess is that you have a better chance with Walter, but I don't know. Regardless, I think that it would need to be shown that the proposed syntax would be a significant improvement to a lot of the existing code out there. Andrei in particular seems to be becoming more insistent on that point and less likely to agree that something is worth adding to the language when it can be done with a library solution.

Personally, I see little value in any of the suggested syntactic sugar involving ?; either we already have a library solution that works just fine (e.g. Nullable), or it's something that I do so rarely in my D code that, I'd likely never use it. There probably are a few places in Phobos where they could be used, but idiomatic D code simply doesn't do much with null. Structs are heavily used, whereas classes are rarely used, and dynamic arrays (strings included) are designed so that null and empty are mostly synonymous. And while pointers do get used some, the focus is generally on static allocations where possible, which significantly reduces the number of heap allocations in comparison to typical C# or Java code. Particularly, when doing a lot with ranges, null doesn't tend to enter into things much. I rarely find that I need to check for null.

But anyone wanting such additions would need to convince Walter and Andrei, not me.

- Jonathan M Davis

On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
> Hi,
> I had been using D for almost 6 years and I want to share my opinion with you.
> I don't want to blame anyone but I'll focus more on bad things and possible improvements.
> And this is just how I see D from my perspective.
> (Sorry for my English, I'm too lazy to take the lessons).
>
> [...]
>
> Thanks for your time.
> - Satoshi

I'm surprised that you didn't mention pattern matching. I really like it in Rust.

On Friday, 20 October 2017 at 20:05:51 UTC, jmh530 wrote:
>> Interesting proposals, but IMHO, the only ESSENTIAL feature missing in D is the possibility to program in D using a built-in reference-counting based variant of the standard library.
>>
>
> Look at the goals for H2 2017
> https://wiki.dlang.org/Vision/2017H2
> The top three things: 1) @safety, 2) @nogc, 3) betterC. Under #2, it specifically says safe reference counting. It's getting worked on...

Yes, it's being worked on, but it's also a huge topic to come up with @safe memory management approach. It's literally about eradicating one of the biggest security bug classes, use-after-free.

Currently I'm working towards an ORM library starting at I/O (https://github.com/MartinNowak/io) to better inform the necessary design.

We already found couple of interesting litmus tests, like the window in iopipe.

auto window = iopipe.window;
iopipe.extend(512); // invalidates window :/
window[0]; // use after-free

Another thing that Walter previously found out is that exceptions are a major hassle for @nogc. I don't like the RC Exception solution much though, as it's a fairly specific workaround (https://github.com/dlang/druntime/pull/1804).

Towards that goal, making exception nesting optional and providing access to the current Exception in flight would allow to use the staticError approach in most places.
https://github.com/dlang/druntime/blob/bc832b18430ce1c85bf2dded07bbcfe348ff0813/src/core/exception.d#L683

Recently I wondered why we cannot semantically transform exceptions to the equivalent of function calls.

- throw Uniq!Exception; // ctor, some struct that's implicitly convertible to a Throwable

- catch (scope Exception e) // handler 1
{
    throw e; // basically continue to unwind
}

- catch (scope Exception e) {} // handler 2

- done unwinding, destroy thrown value

We still support gotos in catch handlers, but should be possible to call destructors in catch handlers anyhow.
https://github.com/dlang/druntime/pull/1804/files#diff-f3953348bb302c27a8cea926c62c02e6R69

On Friday, 20 October 2017 at 18:11:50 UTC, Adam D. Ruppe wrote:
> On Friday, 20 October 2017 at 16:36:28 UTC, jmh530 wrote:
>> It might help to have some sense of how the main devs time on D is being used.
>
> Definitely, I currently have no clue what they are on.

Tried that, didn't resonate that much, and is also quite some work.
So we mostly stick to internal discussions atm.
https://forum.dlang.org/post/o2g7mg$12oa$1@digitalmars.com

Timelines and planning also don't work too well with volunteering.

On Friday, 20 October 2017 at 22:25:20 UTC, Adam Wilson wrote:
> For example, ?? and ?. are ridiculously common idioms that we all perform every day in our D code. And as Mr. Ruppe rightly pointed out, it'd probably take about an hour each to knock together a complete PR for these features.

Well, ignoring communication doesn't make it unnecessary.
It just means that the communication has to happen after throwing a drive-by PR at us.

Would be great if we could adequately capture arguments to facilitate those discussions.
Seems like there wasn't even an ER for that https://issues.dlang.org/show_bug.cgi?id=17924.

On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:

> async/await (vibe.d is nice but useless in comparison to C# or js async/await idiom)


> Reference counting when we cannot use GC...


If I understand correctly, both of these depend on implementation of 'scope' which is being worked on right now.

I think reference counting needs 'scope' to be made safe. RC also benefits from scope in that many of the increments/decrements of the ref count can be elided. The performance gain can be significant, and even more so when you use atomic reference counting (like C++ shared_ptr) for thread safety.

Async/Await needs to allocate state for the function's local variables. When it's detected that the function's state/enumerator won't escape it's current scope, it can be put on the stack, which is a pretty big optimization.

I should also note that, RC has been formally acknowledged as a future goal of D, but as far as I know, async/await has not.

On 10/21/17 9:47 AM, Martin Nowak wrote:
> On Friday, 20 October 2017 at 18:11:50 UTC, Adam D. Ruppe wrote:
>> On Friday, 20 October 2017 at 16:36:28 UTC, jmh530 wrote:
>>> It might help to have some sense of how the main devs time on D is being used.
>>
>> Definitely, I currently have no clue what they are on.
> 
> Tried that, didn't resonate that much, and is also quite some work.
> So we mostly stick to internal discussions atm.
> https://forum.dlang.org/post/o2g7mg$12oa$1@digitalmars.com
> 
> Timelines and planning also don't work too well with volunteering.

Martin's levelheaded answers are much appreciated. (For what it's worth I've been traveling a fair amount recently which brings money in Foundation's coffers and more attention to the D language. I am coping with the unpleasant reality I haven't written real code in months.)

The matter discussed in this thread seems to have been suddenly rendered political, which is why I find it opportune to intervene - in all likelihood, improving nothing :o).

Sticking to technical points, some of the original points are easy to explain as misunderstandings (e.g. safe/system/trusted - yes all three are needed), whereas others can be converted productively into real steps forward for the language.

Using the topic of the Elvis operator as a running example, a good DIP would contain motivation such as:

* Present evidence of the successful use of ?: in other languages

* Present evidence of workarounds being used in D such as orElse, lazyElse etc.

* Present evidence of the usefulness of the ?: operator in gcc, see https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Conditionals.html

* Show how production code fragments in dmd, phobos, or other codebases would be significantly improved by the use of the operator

Yes, there's no guarantee that such a DIP would be approved. But the "need a relationship with the cabal to get things in" angle is very damaging to our community. So is the framing of the language enhancements topic as a fight against arbitrary prejudice. These kind of allegation discourage people from putting good work in, which is all that's needed.


Andrei