My two cents

[Satoshi]

On Friday, 20 October 2017 at 08:32:36 UTC, 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 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.
>> >>
>> >> > [...]
>> >>
>> >> 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

OK, you are right, except one thing.
I think, saving a bit of typing and making the code look prettier 
is acceptable reason to add syntactic sugar. Actually, it's 
definition of syntactic sugar.

I accept that the authors of D have their own line on s. sugar, 
but ideal opensource project should fulfills the requirements of 
the majority not represent subjective opinion of one.


Personally, I had 3 options:
1. Use D and be angry every time when I must write getOne(foo, 
null) instead of foo ?? null and similar stuff.
2. Use different language, like C#
3. Fork D and implement the stuff by myself

Actually, I chose C# just because I need to get project done ASAP 
and don't have time to implement the missing things by myself.

Personally, I prefer user friendliness over fast performance 
because performance can be upgraded by upgrading hardware, but 
development speed cannot.


If you need reason why is writing less code better just calculate 
the time of it.
getOne(foo, null)  // costs 3 sec.
foo ?? null // cost 1 sec.

if you need to write it for 10 times per day and you have company 
with 100 developers it costs 2000 sec (33 min) per day.

It's 132 hours per year. And still, you are writing ugly code.