static foreach(name; ["boo", "foo"]){
    string file_#name = readText(name~".txt");
    string file_#name#_info = readText(name~".meta");
    auto ##name = file_#name#_info.parseInfoFile;
}

writeln(file_boo);
writeln(boo);
writeln(file_foo_info);

To make it easier to read/write code in D, I would introduce new mixins. These mixins can only represent identifiers. Also, the advantage of such mixins, the parser and semantic analysis will be able to detect some errors before the code is completely "opened". Also, I think they can speed up compilation.

On Saturday, 29 January 2022 at 21:24:09 UTC, mesni wrote:

static foreach(name; ["boo", "foo"]){
    string file_#name = readText(name~".txt");
    string file_#name#_info = readText(name~".meta");
    auto ##name = file_#name#_info.parseInfoFile;
}

writeln(file_boo);
writeln(boo);
writeln(file_foo_info);

I believe a DIP would be necessary, but to be honest I don't see a reason for this.

You can just do this which isn't really much less readable.

    static foreach (name; ["boo", "foo"])
    {
        mixin(`string file_%1$s = readText("%1$s.txt");`.format(name));
    }

    writeln(file_boo);
    writeln(file_foo);

And if D ever gets interpolated strings then the whole format can be removed and it could probably become something like this:

    static foreach (name; ["boo", "foo"])
    {
        mixin(i`string file_$name = readText("$name.txt");`);
    }

    writeln(file_boo);
    writeln(file_foo);

So personally I don't see a reason for your suggestion to be added.

I think it's just going to introduce more complexity than it's worth.

On Saturday, 29 January 2022 at 21:24:09 UTC, mesni wrote:

static foreach(name; ["boo", "foo"]){
    string file_#name = readText(name~".txt");
    string file_#name#_info = readText(name~".meta");
    auto ##name = file_#name#_info.parseInfoFile;
}

A general feature for this has been suggested several times before by various people (initially in 2009!). (I noticed your syntax above seems to flip the meanings of the C preprocessor operators though, where stringize is # and concatenate is ##). The other proposal is to allow mixin(str) anywhere an identifier is expected. It was mentioned in the static foreach DIP:
https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1010.md#mixin-identifiers

The nice thing about re-using string mixin syntax for this is that (since then) it can take multiple arguments which the compiler concatenates. So this would work:

static foreach(n; [1,2,3]) {
    int mixin("foo", n) = n;
}
assert(foo1 == 1);

Yes, parsing would be a bit quicker vs putting the whole declaration in a string with CTFE string concatenation. Parsing error messages would be much easier to deal with, besides the likelihood of errors being lower anyway as the code would be much more readable.

On Monday, 31 January 2022 at 07:19:49 UTC, bauss wrote:

    static foreach (name; ["boo", "foo"])
    {
        mixin(`string file_%1$s = readText("%1$s.txt");`.format(name));
    }

    writeln(file_boo);
    writeln(file_foo);

Using std.format for this incurs a substantial compile-time performance penalty--dozens of templates must be instantiated, memory must be allocated for CTFE, the format string must be validated, etc. If the mixin is inside a template which is itself instantiated many times, this overhead can really add up.

On Monday, 31 January 2022 at 20:45:53 UTC, Paul Backus wrote:

    static foreach (name; ["boo", "foo"])
    {
        mixin(`string file_%1$s = readText("%1$s.txt");`.format(name));
    }

    writeln(file_boo);
    writeln(file_foo);

You have to balance that (which in the absence of benchmarks or other empirical evidence is a theoretical problem) against the horrendous cost in terms of complexity of the language. It's not just the syntax - which would be a substantial burden for new users - but also understanding the details of what it's doing. It's hard to see this being worthwhile for only gains in compilation time.

On Tuesday, 1 February 2022 at 01:52:25 UTC, bachmeier wrote:

This is a fair criticism of the original proposal. However, allowing the standard string mixin syntax to be used for identifiers in declarations, as suggested by Nick Treleaven in his reply, would bring the same benefits with significantly less complexity.

On Tuesday, 1 February 2022 at 01:52:25 UTC, bachmeier wrote:

IMHO, in the long term, reading code like this with C like format will take more than memorizing a few rules.

On Tuesday, 1 February 2022 at 01:52:25 UTC, bachmeier wrote:

IMHO, in the long term, reading code like this with C like format will take more than memorizing a few rules.

On Monday, 31 January 2022 at 20:45:53 UTC, Paul Backus wrote:

String mixins should be discouraged, not encouraged. Adding more band aids or special cases is not the right approach.

If compile time string processing is the root issue then one shouldn't solve that by changing the semantics of mixin(). That performance issue can be fixed by introducing classic string interpolation.

On Wednesday, 2 February 2022 at 12:19:57 UTC, Ola Fosheim Grøstad wrote:

String mixins can be used for declarations, expressions or types. The special case is actually that they can't be used for an identifier. People even expect that to work - from the learn forum:

https://forum.dlang.org/thread/ngfkwcyqjtnqhofoqrew@forum.dlang.org

String interpolation would be pretty much just as bad for performance because it still requires the entire declaration to be put in a string, rather than just an identifier. That whole string needs to be formatted and turned into code, when we'd rather be reading code in the first place!