Front page | perl.perl5.porters |
Postings from June 2017
* Abigail <abigail@abigail.be> [2017-06-09T12:40:11]
> On Fri, Jun 09, 2017 at 09:24:53AM -0600, Karl Williamson wrote:
> > I think it is correct to allow the & case where the non-downgradable
> > characters don't figure in the output.
> [...]
> I think it should be deprecated. Allowing some characters in a string
> as an argument to a bitwise operator to exceed 0xFF, but not allowing
> others, the decisions which are and which aren't to be determined by the
> length of the other argument, and the operator just makes it harder to
> explain the language.
Firstly, I apologize if, by trimming the quoted bits, I have changed any
meaning. I think I have not.
I agree with Abigail: it becomes hard to explain.
I see this operation in relation to:
~$ perl -e 'use warnings; my $str = "\x{1000}"; open(my $fh, "<", \$str)or die;'
Strings with code points over 0xFF may not be mapped into in-memory file handles
Died at -e line 1.
Here, we don't say "it's valid until you seek or read into an illegal
position."
The argument can be made that waiting until read time is different than
checking operand length, because read may occur later, and may feel more like
spooky action at a distance. I don't think it's argument enough. We'd be
getting pretty fiddly about the fatality semantics of the operator, and, I
think, without much gain.
> I also think the use case ("it can tell you the status of the internal
> flags") a bit dodgy. Does p5p want to commit to keeping '$var ^ ""' tell
> you the status of the internal flags? If not, then a future change may
> break the $var ^ "" trick in a different way.
Same.
--
rjbs
Thread Previous
|
Thread Next