In that case, I misunderstood whose thought you were referring to and had taken you mean the originator of the coding style rather than the one using it.

When there are defined standards and well-known semantics, I'd love to here about them.

The defined standard is documented in perlre and the well-known default semantics are those which are used in the absence of any modifiers. There are certainly times when the default semantics need to be changed, thus the standard includes modifiers such as /s to alter them, but this does not change my original point that it is generally better to stick with the default (no modifiers) semantics where possible and only invoke modified semantics when there is a need to do so.

I'm not sure what you mean by standard, because I see nothing about the standard usage of x, s and m in perlre.

You changed from "well-known semantics" to "well-known default semantics". My point is that they're not the same. The semantics of ., ^ and $ are not well-known, since they are context-sensitive. The defaults are overriden regularly — more often than not, in my experience — so relying on the default semantics is no good. If you wanted well known semantics in your code, without loss of functionality, it would have to be done through the enforcement of xms.

The problem is that the world on which xms can be enforced is limited, so the "well-known semantics" would only be well-known within that world. However, that's more consistency in semantics than one would enjoy otherwise.

The default semantics are more well-known than any non-default set of semantics. That is the nature of being the default.

I'm not arguing that the reader of code should blindly assume the default semantics apply in any given case, but rather that there is no cause to request that non-default semantics be applied in cases where the default semantics are more than adequate and, further, that most¹ code out there seems to use the default semantics in most¹ places. By consistently depending on non-default semantics, you may be more self-consistent, but you are less consistent with the rest of the world.

¹ I suspect that "the vast majority" would be more accurate, but I have no proof that such is the case.

and it's often an error not to use s.

It is, but never forget that it can also be a bad to use /s with .. Matching \n just like any other character is not always natural; this default for . is NOT arbitrary or accidentally introduced. It actually makes sense a lot of the time, and in fact, I encounter more line based data than data that's differently delimited.

It actually makes sense a lot of the time

Do you have any examples? I can't think of anything realistic.

• When dealing with line data, I'd be in a while (<FILE>) { chomp; ... } loops, so my data would never have any \n in it.

• When dealing with data where \n is considered whitespace, it's no more special than a space, so I'd use the s modifier.

• When dealing with multiline records, I tend to treat the data as line data — especially if I can use the flip-flop (..) operator — so my data would never have any \n in it. This is probably where I'd be least likely to use the s modifier.

• When dealing with binary data, \n is not special, so I'd use the s modifier.

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!

Juerd # { site => 'juerd.nl', do_not_use => 'spamtrap', perl6_server => 'feather' }