read [1] is an easy way to introduce runtime exceptions into programs, but its documentation doesn't sufficiently warn of this danger. read's safe alternatives, Text.Read.readMaybe [2] and Text.Read.readEither [3], are relatively unknown and too hard to find. To guide users (particularly newcomers) away from read and towards readMaybe and readEither, I propose to 1. Add readMaybe to the Prelude 2. Add readEither to the Prelude 3. Change the documentation for read to point out the partiality and to recommend the above alternatives: The haddocks for read currently read: > The read function reads input from a string, which must be completely consumed by the input process. I propose to add a paragraph roughly like this: > Note: read will throw an error if the parse fails. If there's any uncertainty w.r.t. the shape of the input, readMaybe or readEither should be used instead. Name clashes: A cursory code search on Github for readMaybe [4] reveals many existing definitions, mostly with the same type (Read a => String -> Maybe a) and definition. The same search for readEither [5] shows mostly GHC forks. Design issues: I am somewhat doubtful about the benefit of readEither over readMaybe: While readEither does give additional info on the kind of parse failures, that information is encoded in a String error message, from which it must be parsed if it is needed in the program. As the different parts of the proposal can be implemented independently of each other, please vote separately on each part of the proposal. Discussion period: 4 weeks. Cheers, Simon [1] http://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html#v:read [2] http://hackage.haskell.org/package/base-4.9.0.0/docs/Text-Read.html#v:readMa... [3] http://hackage.haskell.org/package/base-4.9.0.0/docs/Text-Read.html#v:readEi... [4] https://github.com/search?l=Haskell&q=readMaybe&type=Code [5] https://github.com/search?l=Haskell&q=readEither&type=Code