The state of string interpolation

Steven Schveighoffer schveiguy at gmail.com
Fri Dec 7 22:12:18 UTC 2018


On 12/7/18 3:59 PM, H. S. Teoh wrote:
> On Fri, Dec 07, 2018 at 03:13:09PM -0500, Steven Schveighoffer via Digitalmars-d wrote:
> [...]
>> My vision of formatted would be simply a pairing of a format specifier
>> with a value. It would be up to the function to interpret that (i.e.
>> text, or inlineformat or whatever you like).
>>
>> But the point is you are coupling the format with the value in the
>> same place. Which is the idea behind the "named parameters" that you
>> have.
>>
>> I don't want the language to do any sort of formatting at all. That's
>> a library feature. We just need the interpolation feature to give us a
>> nicer way to call it.
> [...]
> 
> I see.  So that means what we really want is for the language to
> translate interpolated strings into tuples that can then be processed by
> library code. In other words, it's not really an interpolated string
> anymore, it's a kind of "tuple literal" with convenient syntax. It has
> general applicability, and can be used for all sorts of interesting
> things beyond just interpolated strings.  Like your database query
> example.  In fact, it can even form the basis for implementing my named
> parameters idea.  Once we have it in tuple form, it can be used for all
> sorts of things.  (Which makes me wonder if we can even make it a
> replacement for std.meta.AliasSeq ...) It would be an enabler of cool
> new D idioms, rather than mere syntactic sugar for a "niche" use case.

I think we are all finally on the same page (which I didn't realize we 
weren't, sorry about that!)

The selling of the idea is the hard part, Jonathan Marler has already 
implemented it, and the spec is super-simple as you say.

I think part of the confusion here is that we are calling it string 
interpolation. It's not the same as what most languages use for string 
interpolation. It's really something more like "string formatted alias 
sequence" or "string interpolation tuple". That should be reflected in 
the actual DIP.

What's central to the utility is that it's based on string literals 
(runtime strings will NOT work here), and therefore, has the potential 
to be used in mixins, and in compile-time alias sequences. Sequences of 
expressions split by strings are so common in D, it just makes complete 
sense to me.

-Steve


More information about the Digitalmars-d mailing list