Proposal: deprecate Prelude.read

[Edward Kmett]

A variant of this that I would support would be to bring readMaybe into
Prelude from Text.Read for a good long time, and *then* to deprecate read.
As it stands, read and the almost equally ugly readIO are the only Prelude
facing ways for a user to really consume a Read instance, so losing read
there is a heck of a blow to usability without a replacement being in place
with an established pattern of usage.

-Edward

On Thu, Oct 14, 2021 at 11:16 PM Emily Pillmore <emilypi at cohomolo.gy> wrote:

> NOPE.
>
>
> On Thu, Oct 14, 2021 at 8:31 PM, Fumiaki Kinoshita <fumiexcel at gmail.com>
> wrote:
>
>> It is a partial function that does not provide a call stack, and it's
>> very slow too.
>>
>> I propose deprecating Prelude.read <http://prelude.read/>. Adding
>> deprecation should not break anything substantial because Hackage rejects
>> -Werror (application code using -Werror is likely to experience a lot more
>> breakage anyway, and I'd say it's their fault if it fails to build due to a
>> use of read along with -Werror).
>>
>> Of course those who still want to use Prelude.read <http://prelude.read/>
>> can totally ignore warnings. I believe this proposal is not that
>> controversial.
>>
>> _______________________________________________
>> 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/20211014/abfb9abd/attachment.html>