Add an options data structure to allow fine-tuned control of what instances are generated for a route

[Benjamin-McRae-Tracsis]

Before submitting your PR, check that you've:

• Bumped the version number
• Documented new APIs with Haddock markup
• Added @since declarations to the Haddocks for new, public APIs

After submitting your PR:

• Update the Changelog.md file with a link to your PR
• Check that CI passes (or if it fails, for reasons unrelated to your change, like CI timeouts)

[parsonsmatt]

So that's going to be a breaking change for any library user that uses the Read instance of the type

To avoid a major breaking change, we need to keep the default behavior of deriving Read, but provide an option for the user to disable Read derivation.

[Benjamin-McRae-Tracsis]

I can try to work on that.

How would you want this configurable? I can make a mkRouteConsOpt that requires a config data structure, which has three booleans: hasShow, hasEq, hasRead, and then make duplicate versions of all the functions that call mkRouteCons that are suffixed with Opts to take said Opts.

[parsonsmatt]

I'm not terribly particular. I think @snoyberg mentioned using a directive in the actual routes file would be fine - maybe something like:

!no-derive-read

as a very quick, patch-level fix.

Defining an Opts type make sense - I'd prefer a specific name (ie RouteDeriveOpts), and ideally a hidden constructor with setter functions so new fields aren't a breaking change. However, since we don't need to use this to derive instances - users can use StandaloneDeriving to write deriving stock Read (Route App), after all - I don't anticipate many changes to this type, so hiding the constructor and setters would be a matter of taste rather than real pragmaticism.

[Benjamin-McRae-Tracsis]

Are there other examples of such directives? I'm looking at the parser and I'm not sure whether there are other directives, and I don't necessarily want to rewrite this parser.

[parsonsmatt]

PR looks great, thank you! I made some suggestions for the version number + @since comments.

[parsonsmatt]

Looks great! Thank you 😄

[Benjamin-McRae-Tracsis]

Is anything else needed for merging?

[parsonsmatt]

CI failures look spurious. I'll merge now.

@snoyberg I don't have maintainer rights on Hackage for yesod-core. Would you be willing to either add me or do an upload here? Thanks!

[snoyberg]

@parsonsmatt absolutely, I'd be happy to. What's your Hackage username?

[parsonsmatt]

It's parsonsmatt there too. Thank you!

[snoyberg]

@parsonsmatt I've given you maintainer rights on Hackage for yesod-core and a bunch of other Yesod packages too. If you need any more, just let me know. Thank you!