On 10/20/17 01:32, Jonathan M Davis wrote:
On Friday, October 20, 2017 08:09:59 Satoshi via Digitalmars-d wrote:
On Friday, 20 October 2017 at 04:26:24 UTC, Jonathan M Davis
wrote:
On Friday, October 20, 2017 02:20:31 Adam D. Ruppe via
Digitalmars-d wrote:
On Friday, 20 October 2017 at 00:26:19 UTC, bauss wrote:
return foo ? foo : null;
where
return foo ?? null; would be so much easier.
return getOr(foo, null);
That's really easy to do generically with a function. I
wouldn't object to the ?? syntax, but if it really is
something you write all over the place, you could just write
the function.
return foo ? foo.bar ? foo.bar.baz ? foo.bar.baz.something :
null;
Which could just be:
return foo?.bar?.baz?.something;
In dom.d, since I use this kind of thing somewhat frequently,
I wrote a function called `optionSelector` which returns a
wrapper type that is never null on the outside, but propagates
null through the members. So you can do
foo.optionSelector("x").whatever.you.want.all.the.way.down
and it handles null automatically.
You can do that semi-generically too with a function if it is
something you use really frequently.
For better or worse, solutions like this are the main reason
that a number of things folks ask for don't get added to the
language. It's frequently the case that what someone wants to
do can already be done using the language as-is; it just may
not be as syntactically pleasing as what the person wants, and
they may not know D well enough yet to have come up with the
solution on their own.
- Jonathan M Davis
Yeah, but if it can be done by stuff like you said it's not
reason to not implement syntactic sugar for it.
array[0 .. 42] can be substituted by array.slice(0, 42) too, but
it's not.
it's more handy to write
void foo(int? a, string? b);
than
void foo(Maybe!int a, Maybe!string b);
same for
return a ?? null;
than
return getOr(a, null);
foo.optionSelector("x").whatever.you.want.all.the.way.down
it's not clear if you are able or not to able to hit the null.
foo?.x?.whatever?.you?.want;
is more clear and doesn't need any boilerplate.
it doesn't need to be implemented in code.
Yes, there is syntactic sugar in the language, and yes, there could be more,
but it reached the point a while ago where Walter and Andrei seem to have
decided that additional syntactic sugar isn't worth it. For something to be
added the language, it generally has to add actual capabilities or solve a
problem that is just unreasonable or impossible to solve with a library
solution.
And honestly, where to draw the line on syntactic sugar is highly
subjective. Something that one person might think makes the code nicely
concise might seem annoyingly crpytic to someone else. And obviously, not
everything can have syntactic sugar. Not everything can be built into the
language. A line has to be drawn somewhere. It's just a question of where it
makes the most sense to draw it, and that's not at all obvious. There's
bound to be disagreement on the matter.
D is an extremely powerful language, and for now at least, the conclusion
seems to be that its power is being underutilized and that it simply isn't
worth adding things to the language if they can be easily done with a
library solution. Obviously, there are things that some folks would like to
be in the language that aren't, but there's always going to be something
that someone wants to be in the language but isn't, and the guys in charge
seem to have decided that D is now featureful enough and powerful enough
that it's not getting new features unless it actually needs them. Simply
making some syntax look prettier isn't enough. A feature has to actually add
capabilities that we're missing. There may be exceptions to that, but that's
generally where things sit.
And honestly, they were going to have to take this stance at some point. We
can't keep adding syntactic sugar forever. They just happen to have stopped
adding syntactic sugar before they added some syntactic sugar that you'd
like D to have.
If you can make a really good argument in a DIP as to why D really needs a
feature that you want, then it may yet get added (even if it's only
syntactic sugar), but it's going to have to be a really compelling argument
that is likely going to need to show why the feature is objectively better
and thus worth having rather than simply saving you a bit of typing or
making the code look prettier. It's probably going to have to clearly reduce
bugs or provide capabilities that can't reasonably be done with a library.
D is long past the point where the language was in flux and we were
constantly adding new features. Features do still get added, but they really
have to pull their own weight rather than being a nice-to-have.
- Jonathan M Davis
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.
I think the purpose of syntax sugar has been fundamentally misunderstood
by grammando's the world over. The purpose of syntax sugar is to give
the most commonly used idioms an expressive short-hand. Some examples of
syntax sugar in the D language are: lambdas, virtual functions, ternary,
I could go on. Some examples of syntax sugar is C# are obvious and have
been previously been mentioned here, for example the ?? operator. Others
are less obvious, for example, async/await is syntax sugar for a
collection of Task-based idioms in C#.
The logical conclusion (reductio ad absurdum) of your argument is coding
in binary. Everything else is just syntax sugar.
Grammando's suffer from a particularly pernicious cognitive bias called
"Functional fixedness" or the inability to use a device in any way other
than it is traditionally used. Grammando's believe that a grammar has
always been a certain way, and that nothing need be added, removed, or
modified. This bias is often enforced by The Curse of Knowledge (I know,
so everyone else must know as well).
The reality is that grammars, like any other social construct, change,
often very rapidly. For example, in English, "ain't" used to be
considered a "high class" word. Within the space of a few short years,
as the low-born began to use it, the high-born rejected it and deemed it
"low-class" and thus you have the situation we have today with that word.
Contractions are the Syntax Sugar of the English language. You use them
everyday without even thinking about it. And the ones you use today are
quite different than the ones you used 10 or 20 years ago. And even the
regional use can vary widely at any given point in time.
Syntax sugar is no different in D than it is in English. For example: a
?? b is a contraction of: a !is null ? a : b which itself is a
contraction of: if (a !is null) { return a; } else { return b; } Indeed,
the CPU only ever sees the last one.
Syntax sugar simply takes the common idioms that the culture around D
has collected and then distills them into expressive forms. As with
spoken language, to declare an "end" to syntax sugar is to declare an
end to the culture that surrounds it. If the language cannot adapt to
the culture changing around it, the language will die, and the culture
will move on.
--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;
