Project Elvis

[bauss]

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.