Start a GoodDefaults file collecting recommended option settings.

[Zimmi48]

Follow-up of Zulip discussion at: https://coq.zulipchat.com/#narrow/stream/237977-Coq-users/topic/Better.20default.20options

Let's keep the momentum on this good idea. I've started populating this file with an easy one. What else should go in there and is not controversial? For instance, I saw Set Universe Polymorphism. being suggested in https://coq.zulipchat.com/#narrow/stream/237977-Coq-users/topic/Your.20favorite.20secret.20Coq.20option.3F, but is it already recommended for all users?

• Added changelog.
• Added / updated documentation.

[TheoWinterhalter]

Thanks for opening this!

I would say the relevant proposals are

• Primitive Projections
• Keyed Unification
• Asymmetric Patterns
• Uniform Inductive Parameters

For sure on the list should be the recommended config for type classes but I don't know it.

[Zimmi48]

If anyone disagrees with the proposed options, please voice your opinion.

BTW, @TheoWinterhalter, you may be able to push changes directly to this branch, in particular if you see the "Add more commits by pushing to the good-defaults branch on Zimmi48/coq." message above the CI status section.

[ppedrot]

I'm a bit wary of the Keyed Unification option, it's probably wildly undertested and thus very buggy.

[SkySkimmer]

We know primitive projections are pretty buggy too.

[Zimmi48]

OK. I advise that we avoid any controversial or insufficiently tested option. We could make a separate file ExperimentalGoodDefaults if we want to include potentially buggy options that we would still like to recommend in the long run.

[SkySkimmer]

I guess we should look through the deprecated warnings to see if any correspond to options that may be flipped.
For instance when we added export locality to hints we could have had an option to make it the default early, and enabled the option in gooddefaults.

[ppedrot]

But if we do that we need to version this file per release...

[Zimmi48]

But if we do that we need to version this file per release...

That's already the case here.

[SkySkimmer]

Versioning it is the whole point in fact. If we didn't version we may as well flip the global defaults.

[TheoWinterhalter]

Thanks @Zimmi48, but I actually don't want to push things, I'm merely listing options that might be worth adding, but I'm myself unsure whether they should, and I think it should be debated.

[proux01]

Since this is a draft, let's remove the milestone.

[Zimmi48]

There was a good reason for the milestone: the file has a version number. If it is not merged in this version, it should be renamed.

[proux01]

Then rename to 8.21 and put in 8.21+rc1 milestone.

[Zimmi48]

Why would I do that, exactly? The documented branching date for 8.20 is 2024-06-17. So if this PR is ready to merge before that date, it can still go in 8.20, no?

[proux01]

Sure

[TheoWinterhalter]

Coming back to this so it doesn't die. I think we would need have a flag to change default hint mode for typeclasses. Currently I think it's + for each argument, but it would be good to set it to ! iinstead. At least that's my understanding.
There is no way to change the default globally yet, correct?

[coqbot-app]

The "needs: rebase" label was set more than 30 days ago. If the PR is not rebased in 30 days, it will be automatically closed.

[coqbot-app]

This PR was not rebased after 30 days despite the warning, it is now closed.

[TheoWinterhalter]

I see #19473 is relevant here.

[jfehrle]

Do you expect these recommendations will over time become the default settings? If changes in the defaults are manageable for users, maybe that would be simpler.

[TheoWinterhalter]

It would be great, but it is much more work, as it can break things on the user side. For now it's what we recommend for new users / files.

[SkySkimmer]

too late for 9.1

[Zimmi48]

@TheoWinterhalter You should put yourself as a co-author in the commit message (using a git trailer).

[Zimmi48]

@anton-trunov seemed to defend the current default in his answer on Stack Overflow back in 2016: https://stackoverflow.com/questions/37211899/purpose-of-maximal-vs-non-maximal-implicit-arguments

That being said, I don't think the issue of having to add @ when you want to refer to a non-partially-applied constant is such a pain.

And on the other hand, the same @anton-trunov supported in 2021 the switch to maximally implicit arguments for lists (which didn't land) in #13069.

[proux01]

Yes, 2016 is old

[proux01]

Just a thought: if those are really good defaults, they should probably be actual defaults. Then the compat file can be used (and recommended in the changelog entry) to retrieve the previous defaults and help transitioning.

[Zimmi48]

Just a thought: if those are really good defaults, they should probably be actual defaults. Then the compat file can be used (and recommended in the changelog entry) to retrieve the previous defaults and help transitioning.

OK, but who does the work of porting external projects to these new defaults? (Although, of course, porting could also mean resetting the flags to their old values in the affected projects.)

[proux01]

Nothing specific to this change compared to any other. Porting is obviously the responsibility of authors. They can simply use the compat file (with option -compat 9.1) if they want to keep the old settings/avoid porting.

[TheoWinterhalter]

I'm not against having them as actual defaults yes. We just thought this experiment had more chances to succeed since we're not messing with anyone.

[proux01]

I fear, this also means more chances to just remained ignored or simply unknown :(

[Zimmi48]

Sure, but this is a better middle ground to doing nothing, which has been what has been done for years for many of these defaults. There were even attempts at changing some of these defaults, which failed (e.g., #17811).

[proux01]

We have a better CI contract now, maybe that would help?

[TheoWinterhalter]

Now that #20820 is merged, I removed the corresponding line in the file.
I also added Set Keyed Unification to please @ppedrot.

[ppedrot]

I would also vouch to set the TC database opaque by default, see #20786.

[TheoWinterhalter]

Done.

[Zimmi48]

This should probably get merged. Then, we will have until the 9.2 release to nitpick the settings / improve the Good Defaults 2025 file before it is frozen forever.

[TheoWinterhalter]

Is there anything we can do to have this PR accepted?
I was thinking maybe the name could be Recommended2025 or RecommendedSettings2025 but I'd prefer it to be merged over bikeshedding (which we can do after, with other PRs).