The state of string interpolation

Steven Schveighoffer schveiguy at gmail.com
Thu Dec 6 23:33:13 UTC 2018


On 12/6/18 6:05 PM, o wrote:
> On Thursday, 6 December 2018 at 22:53:26 UTC, Paul Backus wrote:
>> On Thursday, 6 December 2018 at 22:34:14 UTC, o wrote:
>>> Just think how much nicer this is (lowering to a string):
>>> `foo(i"My name is $name");`
>>>
>>> Compared to this (lowering to a tuple, requiring a conversion to a 
>>> string):
>>> ```
>>> import std.conv: text;
>>> foo(text(i"My name is $name"));
>>> ```
>>
>> You can write `foo` in such a way that the user never has to manually 
>> insert a call to `text`:
>>
>> void foo(string s)
>> {
>>     // do whatever
>> }
>>
>> void foo(Args...)(Args args)
>> {
>>     import std.conv: text;
>>     foo(text(args));
>> }
>>
>> In fact, you can even encapsulate this pattern in a mixin:
>>
>> template interpArgs(alias fun)
>> {
>>     import std.format: format;
>>
>>     enum interpArgs = q{
>>         auto %1$s(Args...)(Args args)
>>         {
>>             import std.conv: text;
>>             return %1$s(text(args));
>>         }
>>     }.format(__traits(identifier, fun));
>> }
>>
>> mixin(interpArgs!foo);
> 
> I think that this just further proves my point. In order use an 
> interpolated string as a real string, you ended up going back down this 
> rabbit-hole of mixins/libraries/templetes. There would be no need for 
> this if `foo(i"a is $a)` was the same as `foo("a is 12")`.

But it's not. It's foo("a is " ~ a.to!string);

I'd rather the allocation(s) be explicit.

foo(i"a is $a".text)

looks good to me, and solves the problem.

-Steve


More information about the Digitalmars-d mailing list