When you use empty hashrefs, are they by themselves, or are they at least assigned to something or used as an arguement to a subroutine? I cannot think of anytime that I've just put an empty structure dangling in the wind. If you do, could you provide an example? I'm genuinely curious.

thor

Feel the white light, the light within
Be your own disciple, fan the sparks of will
For all of us waiting, your kingdom will come

I was thinking of things like this, where the assignment is done later:

sub gimme_my_data {
  my $self = shift;
  $self->{data} || {}
}
[download]

you could use a code block there too if you want to ( || do { ... }).
"What should it profit a man, if he should win a flame war, yet lose his cool?"

I would argue that it is not well written code.

This website is frequently the meeting place for showdowns about "show-off perl" vs "safe perl" programming.

I often write an empty block as follows:

    {
        ;
    }
[download]

usually for the following

    if ($condition_that_should_return_true)
    {
        ; # success!
    }
    elsif (...)
      .
      .
[download]

If you are coding in a manner than can be interpreted a multiple number of ways depending on context, then you should either code within the context, or avoid expressing your statement when you're unsure of the context.

I suggest you have a read of Code Complete. It may make you aware of some programming methodologies that will help you avoid unsafe programming.

A {} by itself, I agree, but when you're given something like {}{} and somebody tells you it's valid code, do you think those are two empty blocks, one empty block and one hashref (in either order), or complain that it looks like two hashrefs and the code is wrong?

But my point is that it isn't valid code, and that even if it was valid code, it would would be useless, despite what people would tell you.

update: If you really want 2 empty blocks, do something like

{ ; }
{ ; }
[download]

"What should it profit a man, if he should win a flame war, yet lose his cool?"

Would {}{} be
1) a block followed by a hash constructor,
2) a hash constructor followed by a block,
3) a hash constructor followed by a hash constructor, or
4) a block followed by a block?

They are not equivalent. At least, they are not equivalent if found at the end of a sub. The syntax error forces the user to disambiguate.

It could only be 1 or 4. An empty hashref that's not at the end of a block, file or list or in a complex expression should be terminated by a semi-colon (like any other (sub)expression). A block is terminated by its closing brace.

My main objection is that it's silly to have a discrepancy between the current behaviour:

{} # hashref
[download]

and the proposed:

{}{} # two blocks...
[download]

So it's best to keep the current behaviour, ie. syntax error. I must say the current syntax error is actually pretty accurate too, so it won't be too hard to find the problem either.
"What should it profit a man, if he should win a flame war, yet lose his cool?"

After all, you give it well written code and it complains about a syntax error.

We all know that { } is overloaded in Perl. It could be the start of a block, and it could be the start of a hashref - and often, context won't tell perl what to expect. So Perl has to guess based on what's inside the braces - but there's nothing inside to help perl, so it guesses "hashref".

And it's not easy to fix - not without a lot of backtracking. What do you think:

    {foo => 1}{}
[download]

Remember that, for speed reasons, perl uses yacc to parse Perl, and not a recursive decent parser.