code review 9680043: fmt.Printf: introduce notation for random access to arg...

fmt.Printf: introduce notation for random access to arguments.
This text is added to doc.go:

        Explicit argument indexes:

        In Printf, Sprintf, and Fprintf, the default behavior is for each
        formatting verb to format successive arguments passed in the call.
        However, the notation [n] immediately before the verb indicates that the
        nth one-indexed argument is to be formatted instead. The same notation
        before a '*' for a width or precision selects the argument index holding
        the value. After processing a bracketed expression [n], arguments n+1,
        n+2, etc. will be processed unless otherwise directed.

        For example,
                fmt.Sprintf("%[2]d %[1]d\n", 11, 22)
        will yield "22, 11", while
                fmt.Sprintf("%[3]*[2].*[1]f", 12.0, 2, 6),
        equivalent to
                fmt.Sprintf("%6.2f", 12.0),
        will yield " 12.00". Because an explicit index affects subsequent verbs,
        this notation can be used to print the same values multiple times
        by resetting the index for the first argument to be repeated:
                fmt.Sprintf("%d %d %#[1]x %#x", 16, 17)
        will yield "16 17 0x10 0x11".

The notation chosen differs from that in C, but I believe it's easier to read
and to remember (we're indexing the arguments), and compatibility with
C's printf was never a strong goal anyway.

While we're here, change the word "field" to "arg" or "argument" in the
code; it was being misused and was confusing.

[r, 2013-05-22 22:45:39]

Hello rsc (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go/

[bradfitz, 2013-05-22 22:59:58]

What's the motivation here?  (there's no bug for background)

Is this for gettext-like i18n stuff?



On Wed, May 22, 2013 at 3:45 PM, <r@golang.org> wrote:

> Reviewers: rsc,
>
> Message:
> Hello rsc (cc: golang-dev@googlegroups.com),
>
> I'd like you to review this change to
> https://code.google.com/p/go/
>
>
> Description:
> fmt.Printf: introduce notation for random access to arguments.
> This text is added to doc.go:
>
>         Explicit argument indexes:
>
>         In Printf, Sprintf, and Fprintf, the default behavior is for
> each
>         formatting verb to format successive arguments passed in the
> call.
>         However, the notation [n] immediately after the % indicates that
> the nth
>         one-indexed argument is to be formatted instead. The same
> notation
>         attached to a '*' for a width or precision selects the argument
> index
>         holding the value. After processing a bracketed expression [n],
>         arguments n+1, n+2, etc. will be processed unless otherwise
> directed.
>
>         For example,
>                 fmt.Sprintf("%[2]d %[1]d\n", 11, 22)
>         will yield "22, 11", while
>                 fmt.Sprintf("%[3]*[2].*[1]f", 2, 6, 12.0),
>         equivalent to
>                 fmt.Sprintf("%6.2f", 12.0),
>         will yield " 12.00". Because an explicit index affects
> subsequent verbs,
>         this notation can be used to print the same values multiple
> times
>         by resetting the index for the first argument to be repeated:
>                 fmt.Sprintf("%d %d %[1]#x %#x", 16, 17)
>         will yield "16 17 0x10 0x11".
>
> The notation chosen differs from that in C, but I believe it's easier to
> read
> and to remember (we're indexing the arguments), and compatibility with
> C's printf was never a strong goal anyway.
>
> While we're here, change the word "field" to "arg" or "argument" in the
> code; it was being misused and was confusing.
>
> Please review this at
https://codereview.appspot.**com/9680043/<https://codereview.appspot.com/9680...
>
> Affected files:
>   M src/pkg/fmt/doc.go
>   M src/pkg/fmt/fmt_test.go
>   M src/pkg/fmt/print.go
>   M src/pkg/fmt/scan.go
>
>
> --
>
> ---You received this message because you are subscribed to the Google
> Groups "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to
golang-dev+unsubscribe@**googlegroups.com<golang-dev%2Bunsubscribe@googlegrou...
> .
> For more options, visit
https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/o...
> .
>
>
>

[r, 2013-05-22 23:50:54]

Yes, it's for internationalization and translation databases and the
like. It's the one piece we can do without invoking masses of language
tables.

-rob

[rog, 2013-05-23 13:27:32]

why one-indexed?

On 22 May 2013 23:45,  <r@golang.org> wrote:
> Reviewers: rsc,
>
> Message:
> Hello rsc (cc: golang-dev@googlegroups.com),
>
> I'd like you to review this change to
> https://code.google.com/p/go/
>
>
> Description:
> fmt.Printf: introduce notation for random access to arguments.
> This text is added to doc.go:
>
>         Explicit argument indexes:
>
>         In Printf, Sprintf, and Fprintf, the default behavior is for
> each
>         formatting verb to format successive arguments passed in the
> call.
>         However, the notation [n] immediately after the % indicates that
> the nth
>         one-indexed argument is to be formatted instead. The same
> notation
>         attached to a '*' for a width or precision selects the argument
> index
>         holding the value. After processing a bracketed expression [n],
>         arguments n+1, n+2, etc. will be processed unless otherwise
> directed.
>
>         For example,
>                 fmt.Sprintf("%[2]d %[1]d\n", 11, 22)
>         will yield "22, 11", while
>                 fmt.Sprintf("%[3]*[2].*[1]f", 2, 6, 12.0),
>         equivalent to
>                 fmt.Sprintf("%6.2f", 12.0),
>         will yield " 12.00". Because an explicit index affects
> subsequent verbs,
>         this notation can be used to print the same values multiple
> times
>         by resetting the index for the first argument to be repeated:
>                 fmt.Sprintf("%d %d %[1]#x %#x", 16, 17)
>         will yield "16 17 0x10 0x11".
>
> The notation chosen differs from that in C, but I believe it's easier to
> read
> and to remember (we're indexing the arguments), and compatibility with
> C's printf was never a strong goal anyway.
>
> While we're here, change the word "field" to "arg" or "argument" in the
> code; it was being misused and was confusing.
>
> Please review this at https://codereview.appspot.com/9680043/
>
> Affected files:
>   M src/pkg/fmt/doc.go
>   M src/pkg/fmt/fmt_test.go
>   M src/pkg/fmt/print.go
>   M src/pkg/fmt/scan.go
>
>
> --
>
> ---You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[minux1, 2013-05-23 14:00:19]

On Thu, May 23, 2013 at 9:27 PM, roger peppe <rogpeppe@gmail.com> wrote:

> why one-indexed?

one-based index is also used by C.
so that we can think the 0-th parameter is taken up by the format string
itself?

i love this syntax as it's much intuitive than C's "%1$*2$d".
i'm not sure about the relative order or [] and the corresponding action
character.

given that we already are incompatible with C, how about we use:
         fmt.Sprintf("%[2]*.[1]*[3]f", 2, 6, 12.0) for
fmt.Sprintf("%6.2f", 12.0),
instead of:
         fmt.Sprintf("%[3]*[2].*[1]f", 2, 6, 12.0) for
fmt.Sprintf("%6.2f", 12.0),

so that the index will always immediately precede the the thing that it
affects.

[r, 2013-05-23 14:18:30]

Lucio suggested that too. Since we're breaking C compatibility, if we
ever had it, it could go that way. I'm not totally convinced it's
worth it, since this is only ever used to do translation tables and
they don't do much width-oriented stuff, but maybe if the facility
were nicer it would be used more. It's trickier to implement but maybe
not too much. I'll look into it.

Besides being what C uses, one-indexing feels right to me as well,
it's always the "first argument", as well as being (in Printf and
Sprintf) the index in the call.

-rob


On Thu, May 23, 2013 at 6:59 AM, minux <minux.ma@gmail.com> wrote:
>
> On Thu, May 23, 2013 at 9:27 PM, roger peppe <rogpeppe@gmail.com> wrote:
>>
>> why one-indexed?
>
> one-based index is also used by C.
> so that we can think the 0-th parameter is taken up by the format string
> itself?
>
> i love this syntax as it's much intuitive than C's "%1$*2$d".
> i'm not sure about the relative order or [] and the corresponding action
> character.
>
> given that we already are incompatible with C, how about we use:
>          fmt.Sprintf("%[2]*.[1]*[3]f", 2, 6, 12.0) for
> fmt.Sprintf("%6.2f", 12.0),
> instead of:
>          fmt.Sprintf("%[3]*[2].*[1]f", 2, 6, 12.0) for
> fmt.Sprintf("%6.2f", 12.0),
>
> so that the index will always immediately precede the the thing that it
> affects.

[rog, 2013-05-23 15:07:27]

On 23 May 2013 15:18, Rob Pike <r@golang.org> wrote:
> Lucio suggested that too. Since we're breaking C compatibility, if we
> ever had it, it could go that way. I'm not totally convinced it's
> worth it, since this is only ever used to do translation tables and
> they don't do much width-oriented stuff, but maybe if the facility
> were nicer it would be used more. It's trickier to implement but maybe
> not too much. I'll look into it.

+1 - it seems quite a bit more intuitive.

> Besides being what C uses, one-indexing feels right to me as well,
> it's always the "first argument", as well as being (in Printf and
> Sprintf) the index in the call.

i was thinking of it as in index into the variadic argument slice,
but the above makes sense too.

[r, 2013-05-23 16:03:36]

I'm unsure what's right here; flags complicate things.  The current
design has the index modify its immediate predecessor, so %[2]x means,
"This spec applies to the second argument."  You are advocating that
it instead mean, "The following verb applies to the second argument."
That doesn't tell me whether the right syntax is in the presence of
flags. Currently it would be %[2]#x, but in the proposed change if the
index modifies the verb, where does that mean the index should go?
%[2]#x? %#[2]x? Either? The thing is, the entire directive applies to
the second argument, which is why it makes sense to bind it to the %.
If you bind it to the verb, it misses the point that all the other
elements of the format also apply to argument 2.

I'm inclined to leave it alone.

-rob

[r, 2013-05-23 16:15:54]

Let me retract that inclination, because I really am unsure. I'm still
thinking about it.

-rob

[r, 2013-05-23 16:29:14]

Here's the argument that convinced me the new proposal is better: With
it, in the most general case (%[1]*.[2]*[3]f), it puts the arguments
to be fetched in the same order they would be fetched if the index
expressions were not there.

I'll update the CL.

-rob

[r, 2013-05-23 16:51:06]

Hello rsc@golang.org, bradfitz@golang.org, rogpeppe@gmail.com,
minux.ma@gmail.com (cc: golang-dev@googlegroups.com),

Please take another look.

[minux1, 2013-05-23 20:21:44]

could you please re-upload?
I got "error: old chunk mismatch" for patch set 2.

also, please update CL description.

[r, 2013-05-23 20:23:45]

done.

[pja, 2013-05-24 11:28:03]

I have a rather philosophical question: What determines if changes such as 
this violate the Go backwards-compatibility promises? In this case only 
contrived examples such as 
http://play.golang.org/p/FUYtQbI4IT would change, yet the behaviour of this 
is determined by the documentation of error-conditions in package fmt.

http://golang.org/doc/go1compat.html
http://golang.org/pkg/fmt/ -> Format errors

Clearly this change is unlikely to break any real programs, and it sounds 
like a useful feature. But does the current compatibility document cover 
this sort of change?

On Wednesday, 22 May 2013 23:45:39 UTC+1, r...@golang.org wrote:
>
> Reviewers: rsc, 
>
> Message: 
> Hello rsc (cc: golan...@googlegroups.com <javascript:>), 
>
> I'd like you to review this change to 
> https://code.google.com/p/go/ 
>
>
> Description: 
> fmt.Printf: introduce notation for random access to arguments. 
> This text is added to doc.go: 
>
>          Explicit argument indexes: 
>
>          In Printf, Sprintf, and Fprintf, the default behavior is for 
> each 
>          formatting verb to format successive arguments passed in the 
> call. 
>          However, the notation [n] immediately after the % indicates that 
> the nth 
>          one-indexed argument is to be formatted instead. The same 
> notation 
>          attached to a '*' for a width or precision selects the argument 
> index 
>          holding the value. After processing a bracketed expression [n], 
>          arguments n+1, n+2, etc. will be processed unless otherwise 
> directed. 
>
>          For example, 
>                  fmt.Sprintf("%[2]d %[1]d\n", 11, 22) 
>          will yield "22, 11", while 
>                  fmt.Sprintf("%[3]*[2].*[1]f", 2, 6, 12.0), 
>          equivalent to 
>                  fmt.Sprintf("%6.2f", 12.0), 
>          will yield " 12.00". Because an explicit index affects 
> subsequent verbs, 
>          this notation can be used to print the same values multiple 
> times 
>          by resetting the index for the first argument to be repeated: 
>                  fmt.Sprintf("%d %d %[1]#x %#x", 16, 17) 
>          will yield "16 17 0x10 0x11". 
>
> The notation chosen differs from that in C, but I believe it's easier to 
> read 
> and to remember (we're indexing the arguments), and compatibility with 
> C's printf was never a strong goal anyway. 
>
> While we're here, change the word "field" to "arg" or "argument" in the 
> code; it was being misused and was confusing. 
>
> Please review this at https://codereview.appspot.com/9680043/ 
>
> Affected files: 
>    M src/pkg/fmt/doc.go 
>    M src/pkg/fmt/fmt_test.go 
>    M src/pkg/fmt/print.go 
>    M src/pkg/fmt/scan.go 
>
>
>

[rog, 2013-05-24 14:30:57]

On 23 May 2013 17:28, Rob Pike <r@golang.org> wrote:
> Here's the argument that convinced me the new proposal is better: With
> it, in the most general case (%[1]*.[2]*[3]f), it puts the arguments
> to be fetched in the same order they would be fetched if the index
> expressions were not there.

Yes - I was trying to think of a way to say that succinctly
but got distracted.

Thanks.

[bradfitz, 2013-05-24 14:35:26]

On Wed, May 22, 2013 at 4:50 PM, Rob Pike <r@golang.org> wrote:

> Yes, it's for internationalization and translation databases and the
> like. It's the one piece we can do without invoking masses of language
> tables.
>

I'm concerned this isn't the format various translation databases use, so
we'll still need another system to deal with those formats (which isn't
hard), and then we'll have this extra code in fmt.

If you assume this code won't actually help with i18n, is this worthwhile
on its own?

[r, 2013-05-24 15:11:20]

By "the format various translation databases use", do you mean the $
notation? The thing is, our printf isn't compatible anyway, so that
horse has already bolted.

Is this worthwhile on its own? I think so; it covers a common case
(within the subdomain) with a small amount of code.

Doing this stuff at the level of handling multilanguage plurals and so
on is a massive undertaking that does not belong in fmt.

Regarding compatibility, this change breaks no correct format string
except the extremely implausible borderline case of a custom formatter
using %[ as a verb, so I claim it's OK.

-rob

[minux1, 2013-05-24 15:30:01]

On Fri, May 24, 2013 at 7:28 PM, Peter Armitage
<peter.armitage@gmail.com>wrote:

> I have a rather philosophical question: What determines if changes such as
> this violate the Go backwards-compatibility promises? In this case only
> contrived examples such as
> http://play.golang.org/p/FUYtQbI4IT would change, yet the behaviour of
> this is determined by the documentation of error-conditions in package fmt.
>
> http://golang.org/doc/go1compat.html
> http://golang.org/pkg/fmt/ -> Format errors
>
> Clearly this change is unlikely to break any real programs, and it sounds
> like a useful feature. But does the current compatibility document cover
> this sort of change?
>
Making a previously erroneous cases correct is ok as otherwise we can't
implement any
new features to the language. so i think the same could apply to packages
too.

as a concrete example, Go 1.0 doesn't support zip64 in archive/zip, is it
correct for the
user to expect future Go to also return "incorrect format" error for zip64?
No, as zip64 is added in Go 1.1.

[rsc, 2013-05-24 21:49:10]

LGTM

I like the new syntax and semantics.

[minux1, 2013-05-24 21:52:08]

changes look good.

https://codereview.appspot.com/9680043/diff/20001/src/pkg/fmt/print.go
File src/pkg/fmt/print.go (right):

https://codereview.appspot.com/9680043/diff/20001/src/pkg/fmt/print.go#newcod...
src/pkg/fmt/print.go:220: n64, err := w.Write(p.buf)
it could be nitpicking, but
do you mind fixing this naming (n64 probably refers to int64
returned from WriteTo) and the unnecessary cast below?

Thank you.

(there are other cases in this file)

[r, 2013-05-24 22:49:30]

*** Submitted as https://code.google.com/p/go/source/detail?r=e9e3359d9c84 ***

fmt.Printf: introduce notation for random access to arguments.
This text is added to doc.go:

        Explicit argument indexes:

        In Printf, Sprintf, and Fprintf, the default behavior is for each
        formatting verb to format successive arguments passed in the call.
        However, the notation [n] immediately before the verb indicates that the
        nth one-indexed argument is to be formatted instead. The same notation
        before a '*' for a width or precision selects the argument index holding
        the value. After processing a bracketed expression [n], arguments n+1,
        n+2, etc. will be processed unless otherwise directed.

        For example,
                fmt.Sprintf("%[2]d %[1]d\n", 11, 22)
        will yield "22, 11", while
                fmt.Sprintf("%[3]*[2].*[1]f", 12.0, 2, 6),
        equivalent to
                fmt.Sprintf("%6.2f", 12.0),
        will yield " 12.00". Because an explicit index affects subsequent verbs,
        this notation can be used to print the same values multiple times
        by resetting the index for the first argument to be repeated:
                fmt.Sprintf("%d %d %#[1]x %#x", 16, 17)
        will yield "16 17 0x10 0x11".

The notation chosen differs from that in C, but I believe it's easier to read
and to remember (we're indexing the arguments), and compatibility with
C's printf was never a strong goal anyway.

While we're here, change the word "field" to "arg" or "argument" in the
code; it was being misused and was confusing.

R=rsc, bradfitz, rogpeppe, minux.ma, peter.armitage
CC=golang-dev
https://codereview.appspot.com/9680043