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
