Unexpected parse error in function definition involing grouping braces and redirections

[Michael Le Barbier Grünewald]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: darwin14.3.0
Compiler: /usr/bin/clang
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='d\
arwin14.3.0' -DCONF_MACHTYPE='x86_64-apple-darwin14.3.0' -DCONF_VENDOR='apple' \
-DLOCALEDIR='/opt/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H \
-DMACOSX   -I.  -I. -I./include -I./lib  -I/opt/local/include -pipe -Os -DSSH_S\
OURCE_BASHRC -arch x86_64
uname output: Darwin oscar.local 14.3.0 Darwin Kernel Version 14.3.0: Mon Mar 2\
3 11:59:05 PDT 2015; root:xnu-2782.20.48~5/RELEASE_X86_64 x86_64
Machine Type: x86_64-apple-darwin14.3.0

Bash Version: 4.3
Patch Level: 39
Release Status: release

Description:
        Bash reports a parse error on a perfectly valid shell snippet

Repeat-By:
        The following snippet causes bash (see above) report a parse error

        eprintf()
        {
          1>&2 {
            printf "$@"
            printf '\n'
          }
        }

        ./whatever.sh: line 7: syntax error near unexpected token `}'
        ./whatever.sh: line 7: `}’

        It looks like bash considers the first closing brace to mark the
        end of the function.

        This hypothese is supported by the evaluation of the
        following snippet

        failwith()
        {
          1>&2 {
            printf 'Failure: '
            printf "$@"
            printf '\n'
          }
          exit 1
        }
        
        Which causes the script to exit with code 1, while the evaluation
        should have no side-effect besides the definition of the failwith 
function.

        If the redirection operator is removed from the definition, the snippet
        seems to work as expected.

        If this is useful, I also tested the previous snippets in zsh 5.0.5 
where they
        are interpreted as expected.