On 06/14/2017 03:26 PM, Ricardo Signes wrote: > * 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. > I don't yet have a fully formulated opinion on this, but one question I would have is "How is this different from division by 0" that people seem to deal ok with.Thread Previous | Thread Next