From dha@panix.com

Maybe there's a reason for it, but...

~ 12​:35​:18$ perl -wce '$count = 1;'
Name "main​::count" used only once​: possible typo at -e line 1.
-e syntax OK

BUT...

~ 12​:35​:52$ perl -wce 'my $count = 1;'
-e syntax OK

Shouldn't that warning be raised, regardless of scope?

dha

Flags:
    category=core
    severity=medium

Site configuration information for perl v5.6.0:

Configured by fn at Thu May 25 16:23:55 EDT 2000.

Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
  Platform:
    osname=netbsd, osvers=1.4.2, archname=i386-netbsd
    uname='netbsd juggler.panix.com 1.4.2 netbsd 1.4.2 (panix-std) #0: tue apr 25 21:40:45 edt 2000 root@juggler.panix.com:develnetbsd1.4.2srcsysarchi386compilepanix-std i386 '
    config_args=''
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=undef d_sfio=undef uselargefiles=define 
    use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef
  Compiler:
    cc='gcc', optimize='-O', gccversion=egcs-2.91.60 19981201 (egcs-1.1.1 release)
    cppflags='-fno-strict-aliasing -I/usr/local/include'
    ccflags ='-fno-strict-aliasing -I/usr/local/include'
    stdchar='char', d_stdstdio=undef, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, usemymalloc=y, prototype=define
  Linker and Libraries:
    ld='ld', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib
    libs=-lm -lc -lposix -lcrypt
    libc=/usr/lib/libc.so.12.40, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=define, ccdlflags='-Wl,-R/lib '
    cccdlflags='-DPIC -fPIC ', lddlflags='-Bshareable  -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.6.0:
    /net/u/7/d/dha/myperl/i386-netbsd
    /pkg/perl-5.6.0/lib/perl-5.6.0/i386-netbsd
    /pkg/perl-5.6.0/lib/perl-5.6.0
    /pkg/perl-5.6.0/lib/site_perl/5.6.0/i386-netbsd
    /pkg/perl-5.6.0/lib/site_perl/5.6.0
    /pkg/perl-5.6.0/lib/site_perl
    .


Environment for perl v5.6.0:
    HOME=/net/u/7/d/dha
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/local/bin:/bin:/usr/bin:~/jersey/:~/bin:~/jersey/:~/bin
    PERL5LIB=/net/u/7/d/dha/myperl/i386-netbsd
    PERL_BADLANG (unset)
    SHELL=/usr/local/bin/bash

From @schwern

[dha@​panix.com - Fri Jan 05 01​:38​:47 2001]​:

Maybe there's a reason for it, but...

~ 12​:35​:18$ perl -wce '$count = 1;'
Name "main​::count" used only once​: possible typo at -e line 1.
-e syntax OK

BUT...

~ 12​:35​:52$ perl -wce 'my $count = 1;'
-e syntax OK

Shouldn't that warning be raised, regardless of scope?

I agree. In fact the argument for the warning is even stronger for a
lexical. A global seen only once... well maybe some other package grabs
at it. But a lexical declared but never used is useless.

About the only counter argument I can see is that issuing the warning
for lexicals will cause a lot of existing code to start yelping. But
that's what warnings are for. I for one would like to know about unused
lexicals.

From @gannett-ggreer

On Sat Jul 23 01​:55​:34 2005, schwern wrote​:

[dha@​panix.com - Fri Jan 05 01​:38​:47 2001]​:

Maybe there's a reason for it, but...

~ 12​:35​:18$ perl -wce '$count = 1;'
Name "main​::count" used only once​: possible typo at -e line 1.
-e syntax OK

BUT...

~ 12​:35​:52$ perl -wce 'my $count = 1;'
-e syntax OK

Shouldn't that warning be raised, regardless of scope?

I agree. In fact the argument for the warning is even stronger for a
lexical. A global seen only once... well maybe some other package grabs
at it. But a lexical declared but never used is useless.

About the only counter argument I can see is that issuing the warning
for lexicals will cause a lot of existing code to start yelping. But
that's what warnings are for. I for one would like to know about unused
lexicals.

There's a CPAN module for that​:
http​://search.cpan.org/dist/warnings-unused/

Requests to make this a core feature please make a separate ticket.

--
George Greer

@gannett-ggreer - Status changed from 'open' to 'resolved'

From @nwc10

On Wed Jul 28 18​:43​:18 2010, greerga wrote​:

There's a CPAN module for that​:
http​://search.cpan.org/dist/warnings-unused/

Requests to make this a core feature please make a separate ticket.

It would be inappropriate to put that module as implemented in the core.
It's having to jump through hoops in order to provide its functionality,
by overriding the check functions for various operators, storing state
in a hash, and relying on internal features​:

/* Since these APIs are not public, the definitions are a little
complicated */

#if PERL_BCDVERSION >= 0x5010000
# undef PL_tokenbuf /* defined by ppport.h */
# define PL_tokenbuf (PL_parser->tokenbuf)
# define PL_in_my (PL_parser->in_my)
#else
# ifndef PL_tokenbuf
# define PL_tokenbuf PL_Itokenbuf
# define PL_in_my PL_Iin_my
# endif
#endif

The clean correct way to do this in core would be to add code into pad
handling, probably by storing a flag per variable in the pad, and
avoiding the need for check overrides or the overhead of a hash.

Nicholas Clark

@rjbs - Status changed from 'resolved' to 'open'

From PeterCMartini@GMail.com

So, I wrote a patch to do this, but I can't submit that patch as is
because there's quite a few tests that fail (the tests check to make
sure no warnings are triggered, and now they capture the used once warning).

Virtually all of the warnings I've seen are due to this style of code​:

sub {
my ($self, @​args) = @​_;
do_something @​args;
}

Which I suspect exists often enough in the wild that a lot of
scripts/modules would see new warnings if this is enabled ...

Although, code in evals (which includes use and require) doesn't trigger
the used once warning even if use warnings 'once' is enabled, and I see
no reason to make a warning on lexicals used only once behave any
differently.

From [Unknown Contact. See original ticket]

So, I wrote a patch to do this, but I can't submit that patch as is
because there's quite a few tests that fail (the tests check to make
sure no warnings are triggered, and now they capture the used once warning).

Virtually all of the warnings I've seen are due to this style of code​:

sub {
my ($self, @​args) = @​_;
do_something @​args;
}

Which I suspect exists often enough in the wild that a lot of
scripts/modules would see new warnings if this is enabled ...

Although, code in evals (which includes use and require) doesn't trigger
the used once warning even if use warnings 'once' is enabled, and I see
no reason to make a warning on lexicals used only once behave any
differently.

From @iabyn

On Mon, Dec 10, 2012 at 10​:12​:54AM -0800, Peter Martini via RT wrote​:

So, I wrote a patch to do this, but I can't submit that patch as is
because there's quite a few tests that fail (the tests check to make
sure no warnings are triggered, and now they capture the used once warning).

Virtually all of the warnings I've seen are due to this style of code​:

sub {
my ($self, @​args) = @​_;
do_something @​args;
}

Which I suspect exists often enough in the wild that a lot of
scripts/modules would see new warnings if this is enabled ...

Which is probably a good reason not to add such a warning.

--
I thought I was wrong once, but I was mistaken.

From PeterCMartini@GMail.com

On Dec 12, 2012 11​:03 AM, "Dave Mitchell" <davem@​iabyn.com> wrote​:

On Mon, Dec 10, 2012 at 10​:12​:54AM -0800, Peter Martini via RT wrote​:

So, I wrote a patch to do this, but I can't submit that patch as is
because there's quite a few tests that fail (the tests check to make
sure no warnings are triggered, and now they capture the used once
warning).

Virtually all of the warnings I've seen are due to this style of code​:

sub {
my ($self, @​args) = @​_;
do_something @​args;
}

Which I suspect exists often enough in the wild that a lot of
scripts/modules would see new warnings if this is enabled ...

Which is probably a good reason not to add such a warning.

Right. Can the ticket be closed for that reason then? There is an
implementation of a module to do this on cpan, and a note on this warning
in the docs wouldn't hurt.

--
I thought I was wrong once, but I was mistaken.

From @nwc10

On Wed, Dec 12, 2012 at 01​:15​:39PM -0500, Peter Martini wrote​:

Right. Can the ticket be closed for that reason then? There is an
implementation of a module to do this on cpan, and a note on this warning
in the docs wouldn't hurt.

I think fix the documentation to be clear on the "what" and the "why", then
close the ticket.

Nicholas Clark

From @rjbs

On Fri Dec 14 07​:36​:17 2012, nicholas wrote​:

On Wed, Dec 12, 2012 at 01​:15​:39PM -0500, Peter Martini wrote​:

Right. Can the ticket be closed for that reason then? There is an
implementation of a module to do this on cpan, and a note on this warning
in the docs wouldn't hurt.

I think fix the documentation to be clear on the "what" and the "why", then
close the ticket.

When I wrote about this todo a while ago, I suggested that assigning to a lexical was enough
to indicate that it was used. For example, "my $exit = Scope​::Guard->..." is useful, even if
you don't mention $exit again. Similarly, "my ($self, @​x) = @​_" is not madness.

This does mean that we're detecting fewer actually bogus cases. We'd only get variables
declared and use never, rather than used once. (my $x;)

Is that sufficiently useful to pursue? I'm not sure.

From @jkeenan

On Sat Jan 05 11​:20​:05 2013, rjbs wrote​:

On Fri Dec 14 07​:36​:17 2012, nicholas wrote​:

On Wed, Dec 12, 2012 at 01​:15​:39PM -0500, Peter Martini wrote​:

Right. Can the ticket be closed for that reason then? There is
an
implementation of a module to do this on cpan, and a note on this
warning
in the docs wouldn't hurt.

I think fix the documentation to be clear on the "what" and the
"why", then
close the ticket.

When I wrote about this todo a while ago, I suggested that assigning
to a lexical was enough
to indicate that it was used. For example, "my $exit = Scope​::Guard-

..." is useful, even if
you don't mention $exit again. Similarly, "my ($self, @​x) = @​_" is
not madness.

This does mean that we're detecting fewer actually bogus cases. We'd
only get variables
declared and use never, rather than used once. (my $x;)

Is that sufficiently useful to pursue? I'm not sure.

This is the sort of ticket where, the more people think out loud about
it, the farther we get from closing it.

My reading of the ticket leads me to believe​:

* No one is convinced we need any changes in Perl's behavior here.

* No one is convinced of the necessity of a documentation patch -- as no
one has submitted one since the idea was first floated.

It's time to try, once again, to put this ticket out of its 13-year-old
misery. I am taking this ticket for the purpose of closing it and will
do so in 7 days unless someone submits a documentation patch.

Thank you very much.
Jim Keenan

From @nwc10

On Fri, May 17, 2013 at 05​:31​:39PM -0700, James E Keenan via RT wrote​:

On Sat Jan 05 11​:20​:05 2013, rjbs wrote​:

On Fri Dec 14 07​:36​:17 2012, nicholas wrote​:

On Wed, Dec 12, 2012 at 01​:15​:39PM -0500, Peter Martini wrote​:

Right. Can the ticket be closed for that reason then? There is
an
implementation of a module to do this on cpan, and a note on this
warning
in the docs wouldn't hurt.

I think fix the documentation to be clear on the "what" and the
"why", then
close the ticket.

When I wrote about this todo a while ago, I suggested that assigning
to a lexical was enough
to indicate that it was used. For example, "my $exit = Scope​::Guard-

..." is useful, even if
you don't mention $exit again. Similarly, "my ($self, @​x) = @​_" is
not madness.

This does mean that we're detecting fewer actually bogus cases. We'd
only get variables
declared and use never, rather than used once. (my $x;)

Is that sufficiently useful to pursue? I'm not sure.

This is the sort of ticket where, the more people think out loud about
it, the farther we get from closing it.

My reading of the ticket leads me to believe​:

* No one is convinced we need any changes in Perl's behavior here.

* No one is convinced of the necessity of a documentation patch -- as no
one has submitted one since the idea was first floated.

I don't agree with this reasoning. Specifically treating "necessity" as
implying "lack of desirability" and hence "reason to close".

By that reasoning, we would close all wishlist tickets that no-one works on.

It's time to try, once again, to put this ticket out of its 13-year-old
misery. I am taking this ticket for the purpose of closing it and will
do so in 7 days unless someone submits a documentation patch.

I don't agree with this.

The documentation doesn't say clearly that it doesn't apply to lexicals.

A documentation patch is desirable. But anyone could write it. But not
everyone can hack the C code or the build system, so I prioritise my time
on that.

I would welcome a documentation patch that said that the warning doesn't
apply to lexicals. (Or someone to tell me where the fine manual already says
this)

Nicholas Clark

From @ap

* Ricardo SIGNES via RT <perlbug-followup@​perl.org> [2013-01-05 20​:25]​:

When I wrote about this todo a while ago, I suggested that assigning
to a lexical was enough to indicate that it was used. For example,
"my $exit = Scope​::Guard->..." is useful, even if you don't mention
$exit again. Similarly, "my ($self, @​x) = @​_" is not madness.

This does mean that we're detecting fewer actually bogus cases. We'd
only get variables declared and use never, rather than used once.
(my $x;)

Is that sufficiently useful to pursue? I'm not sure.

I feel it would be.

But at that point we are also talking about wholly different concepts​:
“declared but never used” vs “used only once”. It would be strange for
the warning to be thrown if you assign to a global but not if you assign
to lexical, yet at the same time be thrown if you declare a lexical but
never assign to it which for globals is obviously a nonsensical concept.
Clearly there are two different types of occasion here.

So if something is to be implemented for lexicals then it really ought
not to be the same warning.

From @Abigail

On Sat, 05 Jan 2013 11​:20​:05 -0800, rjbs wrote​:

On Fri Dec 14 07​:36​:17 2012, nicholas wrote​:

On Wed, Dec 12, 2012 at 01​:15​:39PM -0500, Peter Martini wrote​:

Right. Can the ticket be closed for that reason then? There is an
implementation of a module to do this on cpan, and a note on this
warning
in the docs wouldn't hurt.

I think fix the documentation to be clear on the "what" and the
"why", then
close the ticket.

When I wrote about this todo a while ago, I suggested that assigning
to a lexical was enough
to indicate that it was used. For example, "my $exit = Scope​::Guard-

..." is useful, even if
you don't mention $exit again. Similarly, "my ($self, @​x) = @​_" is
not madness.

This does mean that we're detecting fewer actually bogus cases. We'd
only get variables
declared and use never, rather than used once. (my $x;)

Is that sufficiently useful to pursue? I'm not sure.

But declaring variables, and never using them can still be very useful.

This is how I write new() in my objects​:

  sub new ($class) {
  bless \do {my $var} => $class; # Or bless do {\my $var} => $class
  }

Here $var is declared, but never used. Unless you count "taking the
reference of it" as "being used".

Abigail

From @xsawyerx

On 01/19/2018 11​:24 PM, Abigail via RT wrote​:

On Sat, 05 Jan 2013 11​:20​:05 -0800, rjbs wrote​:

On Fri Dec 14 07​:36​:17 2012, nicholas wrote​:

On Wed, Dec 12, 2012 at 01​:15​:39PM -0500, Peter Martini wrote​:

Right. Can the ticket be closed for that reason then? There is an
implementation of a module to do this on cpan, and a note on this
warning
in the docs wouldn't hurt.
I think fix the documentation to be clear on the "what" and the
"why", then
close the ticket.
When I wrote about this todo a while ago, I suggested that assigning
to a lexical was enough
to indicate that it was used. For example, "my $exit = Scope​::Guard-
..." is useful, even if
you don't mention $exit again. Similarly, "my ($self, @​x) = @​_" is
not madness.

This does mean that we're detecting fewer actually bogus cases. We'd
only get variables
declared and use never, rather than used once. (my $x;)

Is that sufficiently useful to pursue? I'm not sure.

But declaring variables, and never using them can still be very useful.

This is how I write new() in my objects​:

sub new \($class\) \{
    bless \\do \{my $var\} => $class;  \#  Or bless do \{\\my $var\} => $class
\}

Out of curiosity, what's the benefit of this?

From @Abigail

On Sat, Jan 20, 2018 at 09​:29​:42PM +0100, Sawyer X wrote​:

On 01/19/2018 11​:24 PM, Abigail via RT wrote​:

But declaring variables, and never using them can still be very useful.

This is how I write new() in my objects​:

sub new \($class\) \{
    bless \\do \{my $var\} => $class;  \#  Or bless do \{\\my $var\} => $class
\}

Out of curiosity, what's the benefit of this?

Because all I need of an object is its memory address. "Data inheritance
by default" is, IMO, an extremely lousy way of writing maintainable
programs. So is using hash keys as variables (why bother with strict
if you do so?)

Hence, I don't do that. Instead, I store the objects attributes in lexical
hashes, using the memory address of the object as key. Fieldhashes take
care threads (where the memory address may change) and will clean up
if an object goes out of scope.

Abigail