Front page | perl.perl5.porters |
Postings from July 2017
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