[phobos] expand for std.metastrings

[kenji hara]

> Personally, I consider comma separated formatting to be inlined, or at least inline style
OK, I call the kind of expand "Embedded Formatting" in this
discussion, to avoid confusion.

I again want to emphasize with the Need of Embedded Formatting, with some code.
If you only use built-in string literals, you can't avoid escaping of
code string.
----
enum op = "+";
enum code = "a "~op~" b";
// use "" and manual escaping. It is same with r"" and ``.
enum code = mixin(expand!"a $op b");
// automatically escaping

// quoted string has problem with embedding...
enum code = q{
  struct A{
    enum str = "hello!";
    enum val = a }~op~{ b;  // invalid! can't embed correctly.
  }
};
enum code = "
  struct A{
    enum str = \"hello!\";  // manual escaping!
    enum val = a " ~ op ~ " b;
  }
";
enum code = mixin(expand!q{
  struct A{
    enum str = "hello!";    // automatically escaping
    enum val = a $op b;     // automatically embedding
  }
});  // and editor highlighting will mostly succeed.
----
I DO NOT want to think about escaping of code string!
In this regard, expand is very usuful.

Kenji

2010/11/3 Robert Jacques <sandford at jhu.edu>:
> On Tue, 02 Nov 2010 16:08:11 -0400, kenji hara <k.hara.pg at gmail.com> wrote:
>>
>> The points of text vs expand are:
>> - text is comma separated formatting, expand is inlined formatting.
>
> Personally, I consider comma separated formatting to be inlined, or at least
> inline style, but I understand your point.
>
>> - text is general formatting function, expand is mostly useful in
>> compile-time, and specialized D code formatting for code generation.
>
> And text is both general and works at compile time.
>
>> - editor highlighting issue - my editor does not color q{}, so
>> generating code are colored with normal syntax highlighting. If I use
>> text and its formatting, code readability will be wrong. I don't like
>> it.
>
> I think this is the biggest advantage of it. Well, that and familiarity to
> Perl, PHP, etc, users.
> But the amount/size of code inside these strings need to be pretty large
> before it gets really annoying. For me, your generateFun example (which is
> the only use of expand in interfaces.d) is a two liner, and is simply not
> big enough to start sweating about these issues to me. And most of my large
> mixins for me are generated dynamically; my need for expanding variables in
> long strings is pretty minimal. You wouldn't have/know of a good example of
> a long explicit string mixin requiring non-trivial expansion, would you?
>
> I recognize the benefits of expand, but I'm just concerned about introducing
> yet-another string formating routine, particularly one that looks low-yield
> in terms of power and is rather complex, into phobos.
>
> Part of this problem could be addressed with better documentation, which
> highlights the shell-like syntax and the differences between expand, text,
> Format and ~.
>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>