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.
