[% setvar title Keep default Perl free of constraints such as warnings and strict. %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <table bgcolor="red"><tr><td><font color="white"> Note: these documents may be out of date. Do <b>not</b> use as reference!</font></tr></td></table>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='TITLE'></a><h1>TITLE</h1>
<p>Keep default Perl free of constraints such as warnings and strict.</p>
<a name='VERSION'></a><h1>VERSION</h1>
<pre>  Maintainer: Daniel Chetlin &lt;<a href='mailto:daniel@chetlin.com'>daniel@chetlin.com</a>&gt;
  Date: 3 Aug 2000
  Last Modified: 28 Sep 2000
  Mailing List: <a href='mailto:perl6-language-strict@perl.org'>perl6-language-strict@perl.org</a>
  Number: 16
  Version: 3
  Status: Frozen</pre>
<a name='ABSTRACT'></a><h1>ABSTRACT</h1>
<p>Perl5 is usable with no hassle as a quick-and-dirty problem-solver by
default. It is ideal for one-liners, short scripts, and quick hacks
that have no need for extra protection or error-checking. It is also
great for large projects by making use of the <code>warnings</code> and
<code>strict</code> pragmas.</p>
<p>Perl6 should not make the one-liners, short scripts and hacks need to
jump through extra hoops to get the &quot;lax&quot; behaviour which is default in
Perl5; the point of using Perl as a quick-and-dirty tool is that you
don't have to do anything extra.</p>
<a name='CHANGES'></a><h1>CHANGES</h1>
<p>This RFC, along with RFC 6, sparked a fair amount of discussion on
perl6-language-strict over a month ago. Since then, traffic on -strict
has died down, and nothing new has really been brought to the table that
would affect this RFC.</p>
<p>The only major change to the text of this RFC was to remove a paragraph
stating that this RFC is particularly targeted to keep <code>strict 'vars'</code>
off by default. This paragraph stated that instead of making that
change, the problem with dynamic variables being default be fixed. It
has been removed for two reasons:</p>
<ul>
<li><a name='The author, having seen proposals like RFCs 6, 64, and 106, has decided that making lexical variables default is unlikely to work correctly and usefully.'></a>The author, having seen proposals like RFCs 6, 64, and 106, has
decided that making lexical variables default is unlikely to work
correctly and usefully.</li>
<li><a name='The specifics on lexical vs. dynamic variable defaults have little to do with the real point of this RFC, which is to keep all strictifying pragmas from becoming default.'></a>The specifics on lexical vs. dynamic variable defaults have little to do
with the real point of this RFC, which is to keep <b>all</b> strictifying
pragmas from becoming default.</li>
</ul>
<p>While an RFC discussing/debating/expanding on any of RFCs 6, 64, and 106
might be useful, this RFC is expressly <b>not</b> such a document.</p>
<p>In terms of changes to the real focus of this RFC, there has been little
progress made. The camps are fairly significantly divided between those
who want to make <code>warnings</code> and <code>strict</code> the default for ease of
learning and debugging Perl as well as deploying it for large projects,
and those who want to keep quick, dirty, and easy from becoming harder.
Since the author does not forsee much progress in this disagreement,
this RFC is in a just-pre-frozen state, and is expected to be frozen
within a few days.</p>
<a name='DESCRIPTION'></a><h1>DESCRIPTION</h1>
<p>Perl provides two main ways to ensure &quot;safer&quot;, cleaner, more
maintainable code: the <code>-w</code> switch/<code>warnings</code> pragma and the <code>strict</code>
pragma. It appears likely that Perl6 will improve upon, expand, or add
to this area. Extra functionality and power for these pragmas as well as
additional pragmas (such as the <code>stricter</code> pragma mentioned at TPC)
seem to be a good thing, but none should become default for Perl.</p>
<p>In large projects which require the constraining pragmas, it is not an
issue to take the extra steps and 'use' them. But in quick solutions and
one-liners, it is a major drawback to have to add <code>no strict</code> or
<code>-M-strict</code> for every quick hack or one-liner that would violate the
<code>strict</code> pragma. Some have suggested a shortcut command-line switch
that would disable the constraining pragmas, and others have suggested
that one-liners be exempt from the default. Both of these solutions
would make things somewhat better, but it still does not fit what seems
to have been the philosophy of Perl from day 1: be _lax_ by default, and
allow constrictions to be added by hand.</p>
<p>Perl6 is intended to make the easy things easier and the hard things
possible, just like Perl5 only moreso. While making the constraining
pragmas the default might make hard things very slightly more possible,
it would also make lots of easy things harder, and that is something to
avoid at all costs.</p>
<a name='IMPLEMENTATION'></a><h1>IMPLEMENTATION</h1>
<p>There should be no implementation issues.</p>
<a name='REFERENCES'></a><h1>REFERENCES</h1>
<p>perlrun(1)</p>
<p>strict(3)</p>
</div>