Forum Navigation

Suggested additions to Layout formatting

Moderators: kris

JarrettBillingsley

Joined: 06/21/06

Posts: 26

Posted: 06/09/07 17:26:05

So formatting in Layout (and in everything formatted in Tango) takes a format string as the first param, and then all the things to be formatted as the varargs, much like printf.

Things that I severely miss from Phobos' formatting are (1) the ability to format something without a format string and (2) making any string in the parameter list behave like a formatting string.

I've simulated these changes in MiniD's formatting. A more in-depth explanation is available here.

What do you think? Sean mentioned that it might be a security risk (when printing out a string that shouldn't be used as a formatting string), but Tango (1) catches and formats invalid indices as "{invalid index}", (2) determines how to output a parameter based on the type of the parameter and not on the formatting specifier, and (3) will catch malformed formatting specifiers anyway. I don't know what security risks this poses.

I don't know why I'd make a new scripting language. I mean, I might as well just draw some lines in the sand with a stick.

Author Message

kris

Joined: 03/27/04

Posts: 581

Posted: 06/09/07 22:50:36

those reasons are probably fine, but the rules for indexing become seriously unwieldy. That aspect would need to be resolved first, and it's not clear where the benefit lies anyway?

JarrettBillingsley

Joined: 06/21/06

Posts: 26

Posted: 06/10/07 02:38:12
kris wrote:
those reasons are probably fine, but the rules for indexing become seriously unwieldy. That aspect would need to be resolved first, and it's not clear where the benefit lies anyway?

I wouldn't call them unwieldy. We're already used to:

Stdout.formatln("One: {}, two: {}, three: {}, one: {0}, two: {1}", a, b, c);

That is, we're used to {} having an auto-incrementing index starting at the first argument after the format string; and that {n} accesses the nth element after the format string. That is exactly the same when you allow format strings in the middle.

The only difference then is the "skipping rule". I see this as a logical extension of the auto-incrementing index with Phobos-style formatting: if you use three format specifiers in a string, the next three args will be formatted into it and then will be skipped. So, using an indexed format specifier, anything that you format will be skipped. The implementation is trivial as well -- just have a bool array for the args (Layout already restricts you to 64 args so this can be on the stack), and flag them as "used" as they're used by formatting specifiers, indexed or not.

I don't think it'll be that common for the skipping rule to come into effect, but it's there for consistency. The only difference, then, is when you have something like the following:

Stdout.formatln("X: {1}", y, x);

With the current formatting, this prints out the value of x and y is skipped. With MiniD-style formatting, x is printed, immediately followed by y. But I really can't think of when this would actually come up, even with i18n.

I don't know why I'd make a new scripting language. I mean, I might as well just draw some lines in the sand with a stick.

kris

Joined: 03/27/04

Posts: 581

Posted: 06/10/07 09:13:46

with I18N (the reason for index support) it is common practice to ignore one or more of the arguments provided, depending on the locale and/or context. That is, the format string provides full control over what is and is not formatted along with the order in which arguments are referenced. Both of those are reasons why writefln() is unsuitable for I18N.

JarrettBillingsley

Joined: 06/21/06

Posts: 26

Posted: 06/10/07 15:19:51
kris wrote:
with I18N (the reason for index support) it is common practice to ignore one or more of the arguments provided, depending on the locale and/or context. That is, the format string provides full control over what is and is not formatted along with the order in which arguments are referenced. Both of those are reasons why writefln() is unsuitable for I18N.

I see.

I guess I'll just write my own Layout class. (I guess it is useful to have it as a class after all..)

I don't know why I'd make a new scripting language. I mean, I might as well just draw some lines in the sand with a stick.

kris

Joined: 03/27/04

Posts: 581

Posted: 06/10/07 23:39:43
JarrettBillingsley wrote:
kris wrote:
with I18N (the reason for index support) it is common practice to ignore one or more of the arguments provided, depending on the locale and/or context. That is, the format string provides full control over what is and is not formatted along with the order in which arguments are referenced. Both of those are reasons why writefln() is unsuitable for I18N.

I see.

I guess I'll just write my own Layout class. (I guess it is useful to have it as a class after all..)

^_

being able to swap these things out really is quite handy, and it's how the Tango 'locale' support is handled -- replace the layout instance