Perl should warn or die on mathematical operations on reference implicitly converted to an integer #9929
Comments
From goldstei@ugcs.caltech.eduI'm taking bets on if they think this is a bug or not. My vote is with no. From Joshua David Goldstein <goldstei@ugcs.caltech.edu>, Tue, Oct 27, 2009 at 12:01:03AM -0700:
-- |
From @ap* goldstei@ugcs.caltech.edu (via RT) <perlbug-followup@perl.org> [2009-10-27 09:35]:
Only in semantic nitpicking in that it works as designed. As far as I’m concerned that design is indeed broken, though. Along similar lines I’d also like to eventualy see it become I don’t know how popular this opinion is, though. Regards, |
|
The RT System itself - Status changed from 'new' to 'open' |
From @xdgOn Tue, Oct 27, 2009 at 6:41 AM, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote:
To me, it seems consistent with the idea "use strict 'refs'" -- if -- David |
From @nwc10On Tue, Oct 27, 2009 at 07:00:07AM -0400, David Golden wrote:
Which breaks existing code that uses strict, and the idiom of using the Nicholas Clark |
From @AbigailOn Tue, Oct 27, 2009 at 11:41:45AM +0100, Aristotle Pagaltzis wrote:
I use often stringified references. Either by printing them (debugging Forbidding anything that may lead to an error somewhere else in the Abigail |
From @xdgOn Tue, Oct 27, 2009 at 7:05 AM, Nicholas Clark <nick@ccl4.org> wrote:
That "idiom" is an accident waiting to happen because of overloading. -- David |
From @pjcjOn Tue, Oct 27, 2009 at 11:05:11AM +0000, Nicholas Clark wrote:
And would also reduce the enjoyment we all get at seeing HASH(0x81531d8) -- |
From @xdgOn Tue, Oct 27, 2009 at 7:21 AM, Abigail <abigail@abigail.be> wrote:
Fortunately, you'd still be able to do so in pre-5.10 perl. :-) Making reference stringification a warning wouldn't stop quick and I might be in favor of refaddr() moving into core from Scalar::Util so -- David |
From @AbigailOn Tue, Oct 27, 2009 at 07:21:45AM -0400, David Golden wrote:
What overloading? ;-) *I* know when my code uses overloading. It usually doesn't. It shouldn't
Really? Should strict also forbid using a string as a number? Or I consider 'auto casting' a *feature* of Perl. One I use on a regular
IMO, warnings for situations that are *likely* to be errors are good. Abigail |
From @AbigailOn Tue, Oct 27, 2009 at 07:27:01AM -0400, David Golden wrote:
Ah, but perhaps $hash {refaddr $ref} should warn as well, because it's a disaster waiting to happen. You know, Abigail |
From @nwc10On Tue, Oct 27, 2009 at 07:27:01AM -0400, David Golden wrote:
If "your" module loading is borked, we don't support "you". Nicholas Clark |
From @xdgOn Tue, Oct 27, 2009 at 7:35 AM, Nicholas Clark <nick@ccl4.org> wrote:
Module loading in general. Otherwise, 'use Scalar::Util qw/refaddr/'. -- David |
From @greergaOn Tue, 27 Oct 2009, Aristotle Pagaltzis wrote:
I'd perhaps use it as a "no stringify;" (like "no indirect;") but rolling My favorite stringy-oops has been doing tr// on a list of mixed -- |
From @ap* George Greer <perl@greerga.m-l.org> [2009-10-27 13:15]:
A better name might be something like `no refconv;` (which would
When working with non-trivially nested data it’s not uncommon to And it’s always real tedious to track down where the actual It would be much less painful if you could at least optionally Regards, |
From @ap* Abigail <abigail@abigail.be> [2009-10-27 12:30]:
What does that have to do with anything? We’re talking about
Argument from slippery slope. Please stick to the topic. * Abigail <abigail@abigail.be> [2009-10-27 12:25]:
That’s great. If you want implicit ref conversions, you don’t have to turn on I sometimes turn off strictures too. Not often, but it happens. Regards, |
From @AbigailOn Tue, Oct 27, 2009 at 01:45:18PM +0100, Aristotle Pagaltzis wrote:
That's easy, no additional support needed: { Abigail |
From @ap* Abigail <abigail@abigail.be> [2009-10-27 13:57]:
$ perl -E'{package UNIVERSAL; use overload q[""] => sub {die}, "0+" => sub{die}} say \$_' No cigar. Aside from that: do you have a trick up your sleeve for how to -- |
From @rjbs* Aristotle Pagaltzis <pagaltzis@gmx.de> [2009-10-27T08:45:18]
I believe, but have not Googled, that MJD proposed this some time ago as C< no -- |
From @davidnicolOn Tue, Oct 27, 2009 at 8:02 AM, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote:
Given an alternate universe where all Perl types are "Magic" and look Closer to reality, if plain data was treated more like overloaded Moving stuff from late-bound to earlier-bound is certain to have some |
From @rgarcia2009/10/27 Ricardo Signes <perl.p5p@rjbs.manxome.org>:
No, he proposed it as C<use strict 'refs'> : I think that it should be added in a new pragma. If we add a new strict subpragma, like C<use strict If we add it directly in strict-refs, we loose some granularity. Also |
From @demerphq2009/10/27 Rafael Garcia-Suarez <rgs@consttype.org>:
Have we fixed this is new perls? That is made no strict/no warnings future portable? If not, perhaps we should? Yves -- |
From @AbigailOn Tue, Oct 27, 2009 at 02:40:30PM +0100, Rafael Garcia-Suarez wrote:
I would prefer a new pragma as well, but I don't really understand your
I it were to be added to 'strict-refs' directly, I would stop using strict Abigail |
From @rgarcia2009/10/27 Abigail <abigail@abigail.be>:
Not exactly : to use a new pragma, you have to modify your code, and (I was assuming that C<use strict> continues to enable all strict subpragmas) |
From @pjcjOn Tue, Oct 27, 2009 at 02:40:30PM +0100, Rafael Garcia-Suarez wrote:
I seem to recall that the last time someone wanted a new stricture (FSVO This is a post about strict rather than stringification. I don't have a -- |
From @ap* Abigail <abigail@abigail.be> [2009-10-27 15:10]:
I wouldn’t, but I would strictly oppose conflating them. I can no refconv; -- |
From john.imrie@vodafoneemail.co.ukAristotle Pagaltzis wrote:
In which case somthing like use warnings FATAL => qw(refconv); would be ______________________________________________ |
From @leonerdOn Tue, 27 Oct 2009 11:05:11 +0000
How about a non-default stricture? use strict qw( :default refstring ); -- leonerd@leonerd.org.uk |
Migrated from rt.perl.org#70043 (status was 'open')
Searchable as RT70043$
The text was updated successfully, but these errors were encountered: