Remove the Default instance for ExtrasOptions.

[23Skidoo]

No description provided.

[arybczak]

Why export fields separately?

[23Skidoo]

So that clients would be forced to use

defaultExtrasOptions { eoForceCommit = ...
                     , ... 
                     }

to construct ExtrasOptions values instead of

ExtrasOptions { eoForceCommit = ...
              , ... 
              }

which will break if we add additional ExtrasOptions fields. Also lets us add new fields to ExtrasOptions without bumping the major version.

[jonathanjouty]

+1

That seems to be a common pattern, for example with aeson's Options and defaultOptions:
https://hackage.haskell.org/package/aeson-1.4.3.0/docs/Data-Aeson.html#t:Options

[arybczak]

What if someone wants it to break as they are interested in knowing any new options that might be added in the future?

[jonathanjouty]

@arybczak that's a good point, because adding options without bumping major version might actually be a bad thing. It would constrain us to, and force us to be careful that the default for the newly added field does not affect the behaviour, as otherwise we might be silently breaking clients.

[jonathanjouty]

Although there's a counterargument to that: if the change is significant, say hypothetically eoForceCommit is split into two separate options, then eoForceCommit :: Bool -> ExtrasOptions ceases to exist and becomes a major version bump.

[23Skidoo]

Normally users don't, but I can add an .Internal module.

[arybczak]

Let's not complicate things. Exporting the constructor is fine.

[23Skidoo]

OK, done.

[arybczak]

Apart from the export nitpick it looks good 👍