Deprecate `auto`?

[thumphries]

Haven't really thought this through for more than a minute, but wondering if there's any interest in eventually deprecating auto in favour of more concrete readers.

It's been a reliable source of bugs for me / teams I've worked on, since someone inevitably ends up using auto for a string type or a newtyped string/integral. These tend to appear both when writing initial parsers and when changing code a module or two away, in the same way show tends to create subtle non-local bugs when refactoring.

Would involve adding integralOption / fractionalOption for the cases where you might actually want Read, then deprecating auto. Users who want to keep using custom parsers can use maybeReader / eitherReader so their intent is made clear in the code.

[HuwCampbell]

I'm not super opposed to doing this.

You're right, Read is terrible (and actually doesn't work very well on the command line for most things, due to quoting, Haskell's capitalisation of constructors, and shell expansion primitives). But I do need to balance ease of use and backwards compatibility as well.

integral and fractional would probably cover most use cases where auto currently works cleanly. Are there actually any more?

[thumphries]

I think the other big usage would be times and dates, UTCTime et al. Not many other common types that do pretty-printing via Read. maybeReader of parseTimeM is the right thing to do there, might even be a good canned example for the Haddock...

If you feel like proceeding, would suggest adding a new Read-based function and adding a comprehensive deprecation message so users have to opt in to the sketchy functionality, GDPR-style.

I have been bitten by this enough times that I’ll gladly do the work 😅 let me know how ya feel

On May 31, 2018, at 5:11 PM, Huw Campbell [email protected] wrote:

I'm not super opposed to doing this.

You're right, Read is terrible (and actually doesn't work very well on the command line for most things, due to quoting, Haskell's capitalisation of constructors, and shell expansion primitives). But I do need to balance ease of use and backwards compatibility as well.

integral and fractional would probably cover most use cases where auto currently works cleanly. Are there actually any more?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[quasicomputational]

auto is also good when you're taking an enum-like argument, as dhall-to-cabal does with --print-type. I'd like to replace it with something better, that isn't Read-based and comes with out-of-the-box completion and listing of valid values, which (a) probably means generics, and (b) doesn't exist today.

[paulyoung]

@thumphries pointed out that one can write a monomorphic reader in the meantime, e.g.

import Options.Applicative (ReadM, maybeReader)
import Safe (readMay)

int :: ReadM Int
int = maybeReader readMaybe

[georgefst]

A compromise here might be for the docs to just encourage people to always use an explicit type application with auto.