32

I'm wondering why

use warnings;
use strict;

are not default in Perl. They're needed for every script. If someone (for good reason) needs to disable them, they should use no strict and/or should use some command line argument (for one-liners).

Are there too many badly-written CPAN modules (using "badly" to mean without use strict)? Or is it because this can break a lot of code already in production? I'm sure there is a reason and I would like to know it.

In 5.14 IO::File is loaded automagically on demand, wouldn't it be possible to do something like that with these basic pragmas?

darch
  • 4,200
  • 1
  • 20
  • 23
kobame
  • 5,766
  • 3
  • 31
  • 62
  • possible duplicate of [Why not use strict and warnings in Perl?](http://stackoverflow.com/questions/18064509/why-not-use-strict-and-warnings-in-perl) – Jim G. Aug 10 '13 at 02:41

6 Answers6

53

It's for backwards compatibility. Perl 4 didn't have strict at all, and there are most likely still scripts out there originally written for Perl 4 that still work fine with Perl 5. Making strict automatic would break those scripts. The situation is even worse for one-liners, many of which don't bother to declare variables. Making one-liners strict by default would break probably millions of shell scripts and Makefiles out there.

It can't be loaded automagically, because it adds restrictions, not features. It's one thing to load IO::File when a method is called on a filehandle. But activating strict unless the code did something prohibited by strict is meaningless.

If a script specifies a minimum version of 5.11.0 or higher (e.g. use 5.012), then strict is turned on automatically. This doesn't enable warnings, but perhaps that will be added in a future version. Also, if you do OO programming in Perl, you should know that using Moose automatically turns on both strict and warnings in that class.

cjm
  • 61,471
  • 9
  • 126
  • 175
  • There are many things in Perl 4 that break in Perl 5, like ticks as package specifiers. And never mind that it had no way to specify `strict`; it had no lexical variable scope at all, so it would be impossible for a script that works in Perl 4 to also work in strict Perl 5. The main concern is Perl *5* scripts written without `strict` in mind, especially those one-liners. – Mark Reed May 31 '16 at 22:20
  • 3
    @MarkReed, ticks as package specifiers still work in Perl 5; they're just not recommended (e.g. [Acme::Don't](https://metacpan.org/pod/Acme::Don::t)). AFAIK, most Perl 4 code works in Perl 5 (as long as you don't try to `use strict`). – cjm May 31 '16 at 22:48
  • Well, I'll be jiggered. `perl -MText::CSV -E "say Text'CSV->new"` yields `Text::CSV=HASH(0x7fe1b982ccb0)`. TIL. Thanks! – Mark Reed Jun 01 '16 at 02:05
17

If you are on a modern Perl, say so, you just have to enable it. 5.12 applies strict except for one-liners. It can't be default because of backward compatibility.

$ cat strict-safe?.pl
use 5.012;
$foo

$ perl strict-safe\?.pl 
Global symbol "$foo" requires explicit package name at strict-safe?.pl line 2.
Execution of strict-safe?.pl aborted due to compilation errors.
daxim
  • 39,270
  • 4
  • 65
  • 132
16

Well, use strict is default now, sort of.

Since Perl 5.12.0 if you require a version of Perl >= 5.12.0, then your script will have all the backwards incompatible features turned on, including strict by default.

use 5.12.0;
use warnings;

Is the same as:

use strict;
use warnings;
use feature ':5.12';

It hasn't been turned on more broadly because doing so would break a lot scripts that people depend on to "just work".

Moose also automatically turns on strict and warnings when you use it. So if you do any Moose based Perl OOP, then you get a free pass here, too.

daotoad
  • 26,689
  • 7
  • 59
  • 100
10

It's a philosophical question, not a "it won't work" question.

First, perl has always been under the "you can do it incorrectly if you want" type of paradigm. Which is why there are a lot of perl haters out there. Many would prefer that the language always force you to write good code, but many quick-script-hackers don't want to. Consider:

perl -e '@a = split(/[,:]/, $_); print $a[1],"\n";'

Now, it would be easy to add a 'my' in front of the @a, but for a one line, one-time script people don't want to do that.

Second, yes, I think most of CPAN would indeed need to be rewritten.

There isn't a good answer you'll like, I'm afraid.

Grzegorz Rożniecki
  • 27,415
  • 11
  • 90
  • 112
Wes Hardaker
  • 21,735
  • 2
  • 38
  • 69
  • Why is `$_` needed in that one-liner? – Peter Mortensen Apr 30 '21 at 22:33
  • Good point: it isn't. That isn't the shortest way to do that, but it's the easiest for people to understand. Technically, you don't need the `@a` either and could print directly from the split output as well. But I was trying to be slightly less obfuscated. – Wes Hardaker May 12 '21 at 16:42
1

Both warnings and strict will finally be default (along with some Perl 5 features that were not defaults) with Perl 7. It is expected to be released in the first half of 2021 (with a release candidate maybe around the end of 2020). Maybe it will be out around May 18th to mark the 10 year anniversary of this question? Better late than never!

Ecuador
  • 1,014
  • 9
  • 26
-3

You can use the common::sense module, if you need:

use utf8;
use strict qw(vars subs);
use feature qw(say state switch);
no warnings;
use warnings qw(FATAL closed threads internal debugging pack
                portable prototype inplace io pipe unpack malloc
                deprecated glob digit printf layer
                reserved taint closure semicolon);
no warnings qw(exec newline unopened);

It reduces the memory usage.

cjm
  • 61,471
  • 9
  • 126
  • 175
fvox
  • 1,077
  • 6
  • 8
  • 1
    Unfortunately, `common::sense` isn't very common sense. There are no warnings or strictures that should be turned off by default. – Ether May 18 '11 at 21:26
  • 9
    `common::sense` isn't. Its selection of warnings and strictures it fails to turn on reflects the author's quirks, not good practice. In particular, failing to turn on strict references and undefined warnings is asking for trouble. As for the memory usage claim, while strictly true, it is never seen in practice. Once any other sensible module is loaded, strict and warnings will be loaded. In practice, you wind up using a smidge more memory. Finally, the author is not somebody you want to be contacting for support. – Schwern May 19 '11 at 06:27
  • 1
    @Schwern: It also forgets to turn on `unicode_strings`. And an explicit warnings list means that you may have forgotten some future ones that don’t exist yet, like package warnings. Lastly, you have to delay fatals till runtime, or the compiler misbehaves on error reporting. – tchrist May 19 '11 at 11:19