The state of string interpolation

[H. S. Teoh]

On Fri, Dec 07, 2018 at 07:52:41PM +0000, o via Digitalmars-d wrote:
> On Friday, 7 December 2018 at 17:11:35 UTC, Atila Neves wrote:
> > Every language change is a cost, and therefore should justify its
> > inclusion. I personally don't think that it is in this case just to
> > make a niche use case slightly easier, and this coming from someone
> > from that niche!
> 
> Think about `foreach`, `foreach_reverse`, UFCS, WYSIWYG strings, and
> `switch`. These are all just so-called "niche cases". When you strip
> out all of the syntax "niches" from a language, you are more or less
> left with assembly. Hell, assembly itself is just sugar over pure
> machine code! So with this attitude, why not ditch D and program in
> machine language?

I think the point isn't to throw out all "niche" uses, but to consider
the cost of a new feature *relative to the current state of the
language*.  It's clear that we want certain nice features and
abstractions that would allow us to not have to write assembly directly.
But what is less often recognized / acknowledged is that there's also
only a limited amount of "design space" available for you to put
features into, so to speak.  Furthermore, a good chunk of this "language
real estate" is already occupied by existing language features, so any
additional features needs to be carefully weighed against what's
currently there, in order not to "run out of design space" and start
incurring technical debt.

Well actually, to be more precise, *every* feature comes with a cost
(complexity, syntax, increase in learning curve, etc.), and the cost of
each additional feature compounds with the total cost of current
features (e.g., unexpected/undesired interactions with existing
features).  There's only a finite number of features you can add before
the cost begins to outweigh the benefits (too many features to learn /
remember, too many unexpected interactions between combinations of
features, too complex to implement in a straightforward way, resulting
in implementation bugs, etc.).  As the number of features grow, the cost
of adding even a seemingly-trivial feature also grows.  It doesn't mean
we should never add new features, but it needs to offer substantial
benefits that outweigh the cost of adding (and maintaining!) it.

It would be very nice if we could just throw everything and the kitchen
sink into the language, but it would end up being a monster of a
language (like C++ (j/k :-P)), unwieldy and overly complex.


[...]
> As a side note, Many people have brought up some very good points, but
> the conversation looks like it is now starting to stall. I think we
> should create a DIP template at this point, just to have a place to
> throw out ideas, not committing to anything yet. Then, if we decide to
> actually go through with the DIP, we already have all the
> brainstorming done and in one place. Would someone else (more
> experienced) like to start the DIP, or should I?

If you have the motivation right now, I think you should just go ahead
and draft it up.  The rest of us can help polish it, if need be.  The
worst scenario is if the person most motivated to do it doesn't do it,
then the rest, who are not as motivated, never get around to it. Then
nothing happens and we end up back in square one.


T

-- 
"How are you doing?" "Doing what?"