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.
