Re: Proposal: deprecate Prelude.read

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 wrote:

NOPE.

On Thu, Oct 14, 2021 at 8:31 PM, Fumiaki Kinoshita 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries