On Tuesday, 7 November 2017 at 13:36:19 UTC, Atila Neves wrote:
> On Monday, 6 November 2017 at 19:13:59 UTC, Adam Wilson wrote:
>> On 10/28/17 04:38, Andrei Alexandrescu wrote:
>>> [...]
>>
>>
>> C# has extensive experience with this operator and I think it would be wise to study the history of what they did and why the did it. NOTE: I understand that other languages have it, and there are variations on the theme, but C# has many similarities to D and extensive "in practice" idioms.
>>
>> [...]
>
> My problem with a null coalescing operator is that it bakes in one particular monad into the syntax, and it's not even a monad that's that useful for most idiomatic D code I've seen or written. I'd rather have do notation or something like that.
>
> Atila

There's a big problem in the discussion here.

Everyone opposed to the operator keeps repeating that it's not that useful for most idiomatic D code.

However I'd argue as far to say D has two idioms.

The "low-level" idiom which is what most people would say is a typical D idiom. Passing structs around etc. This idiom is typically seen in the core of D such as Phobos, D Runtime etc.

However there's another idiom to D, which is what I'll call the "high-level" idiom which is mostly people writing applications with libraries such as vibe.d, which heavily relies on classes and reference types passed around, rather then structs. Another example of what I'd call "high-level" idiom is libraries like "dlangui" which also heavily relies on classes, a common idiom for UI applications.

Saying that using classes and types that can be null referenced ins't idiomatic D is wrong IMO.

I agree the elvis operator wouldn't have much purpose without something like the null-conditional operator.

If D truly wants to expand further than a hobby language, then we'd have to focus on enterprise development, which D will never reach with a mentality like this.

C# is a good reference for an ideal language that's fit for enterprise development and D could learn a lot from the language.

I think we have a problem in this community to always bash down things with "It can be solved as a library.", "I don't see the value of this being added.", "I'm not going to use this feature, so nobody else will."

Instead we should be like: "This will make the language more clean, since we don't need to have unnecessary imports and ten different implementations for the same thing.", "Personally this has no value to my code, because of 'X', but I could see how it could help people writing code like 'Y'", "I'm not going to use this feature, but I can see how it might be useful to others."

I understand the mentality of people who believe it has a cost to add something, because it's another idiom to learn, but ask yourself this?

What's easier to learn?

A couple operators (elvis, null-conditional ...) or 10 different module names for all your 3rd party libraries and their implementations doing the same thing as the operators that could be implemented.

Even when something exist in Phobos, people forget about it and end up writing their own implementations that do the exact same, because we're humans and humans forget. Sometimes it can be hard to remember exact modules where some functionality is implemented and that's the down-side of library solutions. You have to remember which module something belongs to.

A language solution however doesn't have that problem, because you don't have to memorize anything other than the syntax of the operators. You don't have to remember any names of modules or any names of functions, their parameters or return types. You just have to remember the operator and in which order it takes its arguments.

Language implementations are usually much simpler and are better suited for optimizations too.

Don't get me wrong though, I don't believe this operator is life or death, neither do I believe that it's one of the most important things to be implemented.

Yes there are other things more important to implement, but it doesn't mean this operator shouldn't be implemented; maybe not now, but in the future.

I believe we're too quick in this community to shut down good ideas, because we believe other problems have better priority.

Instead of shutting good ideas down, we need to queue them, so they don't get shut down, but aren't prioritized.

Yes there are more important things than implementing the so called elvis operator and we should definitely focus on that instead, but we shouldn't entirely shut down the idea of implementing such a feature, just because D has bigger and more prioritized issues.

On Tuesday, 7 November 2017 at 14:08:07 UTC, bauss wrote:
> [snip]
>
> However there's another idiom to D, which is what I'll call the "high-level" idiom which is mostly people writing applications with libraries such as vibe.d, which heavily relies on classes and reference types passed around, rather then structs. Another example of what I'd call "high-level" idiom is libraries like "dlangui" which also heavily relies on classes, a common idiom for UI applications.
>

A DIP could probably include examples of how vibe.d and dlangui handle nulls and how whatever solution is proposed would be simpler.

On Tuesday, 7 November 2017 at 14:08:07 UTC, bauss wrote:
> I think we have a problem in this community to always bash down things with "It can be solved as a library.", "I don't see the value of this being added.", "I'm not going to use this feature, so nobody else will."

It is considered good practice in language design to first insist on a library solution and only implement it in the language iff

1. it turned out to be a useful feature

2. a library implementation was inadequate

Ola.

On Tuesday, 7 November 2017 at 16:32:50 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 7 November 2017 at 14:08:07 UTC, bauss wrote:
>> I think we have a problem in this community to always bash down things with "It can be solved as a library.", "I don't see the value of this being added.", "I'm not going to use this feature, so nobody else will."
>
> It is considered good practice in language design to first insist on a library solution and only implement it in the language iff
>
> 1. it turned out to be a useful feature
>
> 2. a library implementation was inadequate
>
> Ola.

Which this operator has already proven to be in other successful languages.

On Tuesday, 7 November 2017 at 17:27:30 UTC, bauss wrote:
> Which this operator has already proven to be in other successful languages.

Not exactly this variation, but I get your point. On the other hand, so has hundreds of other operators from other languages... So which one should one not implement?

Anyway, I've already shared my viewpoints on the flaws of "?:" as proposed.

On Tuesday, 7 November 2017 at 17:37:42 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 7 November 2017 at 17:27:30 UTC, bauss wrote:
>> Which this operator has already proven to be in other successful languages.
>
> Not exactly this variation, but I get your point. On the other hand, so has hundreds of other operators from other languages... So which one should one not implement?
>
> Anyway, I've already shared my viewpoints on the flaws of "?:" as proposed.

Yes. My point wasn't entirely for the addition of this operator, but in general for every good idea around here.

Honestly I don't care too much if it gets implemented or not. It'll be a great addition, but in my own opinion it's not life or death.

On Tuesday, 7 November 2017 at 13:43:20 UTC, user1234 wrote:
> On Monday, 6 November 2017 at 20:14:17 UTC, Meta wrote:
>> [...]
>> import std.stdio;
>> writeln(safeDeref(tree).right.right.val.orElse(-1));
>> writeln(safeDeref(tree).left.right.left.right.orElse(null));
>> writeln(safeDeref(tree).left.right.left.right.val.orElse(-1));
>>
>> vs.
>>
>> writeln(tree?. right?.right?.val ?: -1);
>> writeln(tree?.left?.right?.left?.right);
>> writeln(tree?.left?.right?.left?.right?.val ?: -1);
>>
>> The functionality is probably a good idea, but a library solution is doable today without any acrobatics.
>
> Show me a library solution that works fine with IDE completion (so for the safe navigation operator, not the Elvis one).

Yes, this is unfortunately the one sticking point of a library solution, although if the front end becomes fully usable as a library it may be possible to an extent.

On Monday, 6 November 2017 at 10:12:11 UTC, Jonathan M Davis wrote:
> On Monday, November 06, 2017 09:26:24 Satoshi via Digitalmars-d wrote:
>> [...]
>
> _Everything_ that is added to the language complicates it further. It's one more thing that everyone learning the language has to learn and know and potentially deal with in code. Obviously, some things are worth the extra complication, or we'd all be programming in C, but there is always a cost to adding something, and the feature needs to be worth that cost.
>
> [...]

I have gone through all the threads and none of the comment argues why we REALLY need Elvis in D. Seem to me like some kind of "language peer influence" or something.

It can be done as a library and using ternary works (more expressive). The problems we need to be solving ...I'm gonna cry :( ...we aren't talking about.

On Wednesday, 8 November 2017 at 07:32:05 UTC, aberba wrote:
>
> I have gone through all the threads and none of the comment argues why we REALLY need Elvis in D. Seem to me like some kind of "language peer influence" or something.
>

Presumably, it's just a more 'elegant' (less verbose) way of doing something that can already be done.

-- taken from: https://kotlinlang.org/docs/reference/null-safety.html#elvis-operator

val l: Int = if (b != null) b.length else -1

Along with the complete if-expression, this can be expressed with the Elvis operator, written ?::

val l = b?.length ?: -1
----------

But I can understand the first example really easily.

The second example, with the elvis operator, I have to spend 'more time' making sure I've interepreted those little symbols correctly. I don't like this syntactic 'elegance' at all. The human brain has too much trouble with it, unless it comes into contact with it often.

So as someone once said, "one has to be very suspicious of the elegant solution" - Butler Lampson 1992.

On Wednesday, 8 November 2017 at 07:32:05 UTC, aberba wrote:
>
> I have gone through all the threads and none of the comment argues why we REALLY need Elvis in D. Seem to me like some kind of "language peer influence" or something.
>
> It can be done as a library and using ternary works (more expressive). The problems we need to be solving ...I'm gonna cry :( ...we aren't talking about.

I'd say add canonical versions of the relevant functions to Phobos first and then if really popular add to language later.