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