Front page | perl.perl5.porters |
Postings from June 2017
On Fri, Jun 09, 2017 at 09:24:53AM -0600, Karl Williamson wrote:
> On 06/09/2017 03:17 AM, Graham Knop wrote:
>> Bitwise operations on wide characters have been deprecated since 5.24,
>> and issue a warning. This has been changed to be fatal in blead.
>> However, the change that is currently in place will die in places that
>> previously didn't get the deprecation warning at all. If one of the
>> strings in a bitwise operation is shorter than where the wide
>> characters exist in the other, no warning would be issued. The
>> resulting string would either stop at the length of the shorter string
>> for &, or have the remaining characters copied unmodified from the
>> longer string for ^ and |.
>>
>> For example:
>> perl -we' my $f = "" & "\x{ABCD}" '
>>
>> This will not warn on 5.26, but is fatal in blead. The change was
>> introduced in 08b6664b858b8fd4b5c0c27542763337b6d78e46.
>>
>> This breaks code that I'm using, including newer versions of JSON::PP.
>> The reason I'm using this is admittedly an abuse of the bitwise ops
>> for number detection. The result of ($var ^ "") can tell you the
>> status of the internal flags for a if value is a valid number, which
>> is needed for serialization. The alternative is using B to examine
>> the flags, which is significantly slower.
>>
>> Doing operations like this doesn't run into the problems motivating
>> the removal of bitwise ops on wide characters, so I would vote for
>> restoring support for it. If that is not an option, there at least
>> needs to be a release cycle with a deprecation warning for this.
>>
>
> I think it is correct to allow the & case where the non-downgradable
> characters don't figure in the output.
>
> I agree that blead needs to change to handle the | and ^ cases so the
> result of the operation is unchanged from previous releases. I don't
> know if this usage should be deprecated or not. I look forward to
> seeing discussion concerning that.
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.
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.
Abigail
Thread Previous
|
Thread Next