Proposal: Deprecate decodeUtf8

Elliot Cameron eacameron at gmail.com
Thu Aug 18 17:33:24 UTC 2016


I like that idea. I've no right to argue with Bryan about his own library,
but "read the docs" is the answer we get in Python, PHP, and Perl. Since
it's demonstrably problematic in this case it seems the docs answer is not
really working.

On Thu, Aug 18, 2016 at 1:19 PM, David Feuer <david.feuer at gmail.com> wrote:

> Being the disruptive sort.... What if we DEPRECATE it for a cycle and then
> change its type? Almost all code that is no longer correct will fail to
> typecheck.
>
> On Aug 18, 2016 12:52 PM, "Bryan O'Sullivan" <bos at serpentine.com> wrote:
>
>> On Thu, Aug 18, 2016 at 2:08 AM, Niklas Hamb├╝chen <mail at nh2.me> wrote:
>>
>>> I propose to add a deprecation pragma to the partial function
>>> Data.Text.decodeUtf8.
>>>
>>
>> I'm not terribly open to adding a pragma for this, I'm afraid. Its
>> documentation already clearly states that it will throw an exception. I
>> understand that developers often fail to read documentation, but I don't
>> want to train them to also ignore compiler output because they get
>> permanent warnings that they can't suppress.
>>
>> I do of course agree that in hindsight, it would have been best to
>> provide a safer function with this name.
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160818/498a6773/attachment-0001.html>


More information about the Libraries mailing list