When dealing with line data, I'd be in a while (<FILE>) { chomp; ... } loops, so my data would never have any \n in it.
Don't forget the single string that contains multiple lines. For the same reason you sometimes want to use /m you sometimes want to match only within a certain line, and then the default . comes in very handy. The difference is that you apparently always read streams line by line, while I like to slurp files from time to time, or get the data in a way that is naturally byte oriented instead of line oriented.
Hmm... given your realistic world of only four possibilities, /m would also never be needed, so I hope you will be able to understand the argument above :-)
You should realise that you or I can never, ever, think of all possible ways that other people think of to use something. Some programming language designers also tried this, and their languages are very much unlike Perl. In Perl 6, some features are provided even without any certainty that they will be used, but a discussion like this one convinces me again and again that I do want those features, because not even Larry Wall can think of all the ways someone would ever use Perl. There are reasons to want to match [^\n] easily, even though you couldn't think of any, and fortunately Perl provides this feature.
And, of course, all these unix tools that behave in exactly the same way should be some indication that even decades ago, already people thought that . matching anything but newline would be very neat!
In reply to Re^6: Best practice or cargo cult?
by Juerd
in thread Best practice or cargo cult?
by robinbowes
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |