My two cents

[Adam Wilson]

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;