develooper Front page | perl.perl5.porters | Postings from January 2018

Re: Behavior of bitwise ops on unencountered wide characters

Thread Previous | Thread Next
From:
Karl Williamson
Date:
January 19, 2018 20:14
Subject:
Re: Behavior of bitwise ops on unencountered wide characters
Message ID:
75f6d0cd-d51b-b96b-e588-b57044cea399@khwilliamson.com
On 12/19/2017 07:16 PM, Karl Williamson wrote:
> On 07/12/2017 11:02 AM, Karl Williamson wrote:
>> On 07/12/2017 04:50 PM, Sawyer X wrote:
>>>
>>>
>>> On 07/11/2017 01:09 PM, Karl Williamson wrote:
>>>> On 07/10/2017 11:12 PM, Father Chrysostomos wrote:
>>>>> Karl Williamson wrote:
>>>>>> 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.
>>>>>
>>>>> Fatal division by zero is ancient.  Fatalizing bitwise operations on
>>>>> utf8 breaks stuff.
>>>>>
>>>>> As I suggested in another thread (I seem to have been ignored), it
>>>>> would be *much* kinder to users to make it a warning.  (Wide character
>>>>> in blah blah blah.)  That way users who care can fatalize it, or sup-
>>>>> press it.  You have the best of all three worlds.
>>>>>
>>>>
>>>> I believe I've referred to your suggestion in some thread.  It is the
>>>> minimum we should do.  And others believe it should be deprecated.
>>>
>>> There is a specific cost here Graham noted. This method is currently
>>> used to determine if a variable is a number without loading "B", which
>>> isn't cheap. While it is a simple argument of "users shouldn't care,"
>>> serializations (like JSON) need to be able to map them to their right
>>> type. It would be nice if there was a way to do this without B.
>>>
>>
>> It would be good to have some alternative that requires only a cheaply 
>> loaded, or internal module, something named like "Internals" that 
>> provides a clear access path for the things we have determined warrant 
>> it, such as Graham's use case.  He had to explain to me how it worked, 
>> and he had to explain to Yves as well.  That demonstrates is is 
>> non-obvious.  When the tools aren't available, people will do clever, 
>> but non-maintainable things to get what they need.  But it is best to 
>> furnish the tools when it becomes known that they would be useful.
>>
> 
> I'm not sure which is the best message on this thread to reply to, so I 
> chose this one.
> 
> I have worked up a patch that deprecates the use of wide characters in 
> bit operations.  Though I'm not sure why we can't just warn forever, 
> like sprout suggested.  My first question is
> 
> 1) Does this really have to be deprecated?  Can a simple warning suffice?
> 
> The patch causes failures in ExtUtils-MakeMaker/t/unicode.t because 
> JSON::PP in blead still uses the trick mentioned on this thread
> 
> I'm not sure what to do.
> 

Well, J:P got updated, and, in the absence of commentary about whether 
the warning should be a deprecation or not, I made it a deprecation as 
the majority of posters earlier had asked.

Commit ba52ce15fe5ca68de1be69e394f41ccb48a731cc

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About