<html><body>
<div dir="ltr">
Here are my new votes, after several discussions, and reading a bit about defaults (like for StarIsType) in the User Guide.</div><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr">-- the ones with comments</div><div dir="ltr">CUSKs: no<br></div><div dir="ltr">-- ^ according to the guide, this is superseded by StandaloneKindSignatures</div><div dir="ltr">ConstrainedClassMethods: yes<br></div><div dir="ltr">-- ^ it is implied by MultiParamTypeClasses anyway</div><div dir="ltr">DefaultSignatures: no<br></div><div dir="ltr">-- ^ as Joachim says, this should be succeeded by DerivingVia</div><div dir="ltr">-- ^ anyway, this is one required for the writer of the class, so no big deal</div><div dir="ltr">DeriveAnyClass: no<br></div><div dir="ltr">-- ^ given our discussion</div><div dir="ltr">DerivingVia: yes<br></div><div dir="ltr">-- ^ even though it’s quite recent, I think it’s quite sensible and I don’t foresee many changes to it</div><div dir="ltr">DisambiguateRecordFields: no<br>DuplicateRecordFields: no<br></div><div dir="ltr">-- ^ we seem to still be working on this</div><div dir="ltr">FunctionalDependencies: maybe<br></div><div dir="ltr">-- ^ this is a hard one! Not so terrible since it’s only required by the creator of the class, not of the instances</div><div dir="ltr">MonadFailDesugaring: yes<br></div><div dir="ltr">-- ^ isn’t this the default nowadays?</div><div dir="ltr">MonoLocalBinds: yes<br></div><div dir="ltr">-- ^ this is implied by GADTs and TypeFamilies</div><div dir="ltr">MultiWayIf: no<br></div><div dir="ltr">-- ^ still in discussion</div><div dir="ltr">NamedWildCards: yes<br></div><div dir="ltr">-- ^ not many people use this, but I think this is the sane default</div><div dir="ltr">OverloadedLists: yes<br>OverloadedStrings: yes<br></div><div dir="ltr">-- ^ I would love to see these included, but I agree with the sentiment that they need more work</div><div dir="ltr">PartialTypeSignatures: no<br></div><div dir="ltr">-- ^ I really think that partial type signatures should not be accepted by default</div><div dir="ltr">QuantifiedConstraints: no<br></div><div dir="ltr">-- ^ too early</div><div dir="ltr">ScopedTypeVariables: yes<br></div><div dir="ltr">-- ^ I think this is really well understood and people want it</div><div dir="ltr">PatternSynonyms: maybe<br></div><div dir="ltr">-- ^ we are still working out the edges of this</div><div dir="ltr">ForeignFunctionInterface: yes<br></div><div dir="ltr">RankNTypes: yes<br></div><div dir="ltr">UnicodeSyntax: yes<br></div><div dir="ltr">-- ^ following Joachim’s suggestion: enable this for syntax but *not* for error messages</div><div dir="ltr">TypeInType: maybe<br></div><div dir="ltr">-- ^ this simply implies PolyKinds, DataKinds, KindSignatures, according to the documentation</div><div dir="ltr">StarIsType: yes<br></div><div dir="ltr">-- ^ this is on by default, and I think it would be very confusing to stop treating “*” different from “Type” as this moment</div><div dir="ltr"><br></div><div dir="ltr">-- these seem simple syntactic extensions</div><div dir="ltr">-- many of them bring compatibility with the syntax of Java-like languages</div><div dir="ltr">BinaryLiterals: yes<br></div><div dir="ltr">HexFloatLiterals: yes<br></div><div dir="ltr">NegativeLiterals: yes<br></div><div dir="ltr">NumDecimals: yes<br>NumericUnderscores: yes<br></div><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr">-- too early but wouldn’t care to introduce it</div><div dir="ltr">StandaloneKindSignatures: yes</div><div dir="ltr">ImportQualifiedPost: yes</div></div><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr">-- don’t know</div><div dir="ltr">GHCForeignImportPrim: maybe</div><div dir="ltr">InterruptibleFFI: maybe</div><div dir="ltr">LexicalNegation: maybe</div><div dir="ltr">NondecreasingIndentation: maybe</div><div dir="ltr">PackageImports: maybe</div><div dir="ltr">ParallelListComp: maybe</div><div dir="ltr">TransformListComp: maybe</div><div dir="ltr">UnliftedFFITypes: maybe<br>UnliftedNewtypes: maybe</div></div><div dir="ltr"><br></div><div dir="ltr">-- the rest</div><div dir="ltr">AllowAmbiguousTypes: no<br>ApplicativeDo: no<br>Arrows: no<br>BangPatterns: yes<br>BlockArguments: no<br>CApiFFI: no<br>CPP: no<br>ConstraintKinds: yes<br>DataKinds: yes<br>DatatypeContexts: no<br>DeriveDataTypeable: yes<br>DeriveFoldable: yes<br>DeriveFunctor: yes<br>DeriveGeneric: yes<br>DeriveLift: yes<br>DeriveTraversable: yes<br>DerivingStrategies: yes<br>EmptyCase: yes<br>EmptyDataDecls: yes<br>EmptyDataDeriving: yes<br>ExistentialQuantification: yes<br>ExplicitForAll: yes<br>ExplicitNamespaces: no<br>ExtendedDefaultRules: no<br>FlexibleContexts: yes<br>FlexibleInstances: yes<br>GADTSyntax: yes</div><div dir="ltr">-- ^ implied by GADTs anyway<br>GADTs: yes<br>GeneralisedNewtypeDeriving: yes<br>ImplicitParams: no<br>ImpredicativeTypes: no<br>IncoherentInstances: no<br>InstanceSigs: yes<br>KindSignatures: yes<br>LambdaCase: yes<br>LiberalTypeSynonyms: no<br>LinearTypes: no<br>MagicHash: no<br>MonadComprehensions: no<br>MultiParamTypeClasses: yes<br>NPlusKPatterns: no<br>NamedFieldPuns: yes<br>NoImplicitPrelude: no<br>NoMonomorphismRestriction: yes</div><div dir="ltr">NoPatternGuards: no<br>NoTraditionalRecordSyntax: no<br>NullaryTypeClasses: yes<br>OverlappingInstances: no<br>OverloadedLabels: no<br>PolyKinds: yes<br>PostfixOperators: yes<br>QualifiedDo: no<br>QuasiQuotes: no<br>RebindableSyntax: no<br>RecordWildCards: yes<br>RecursiveDo: no<br>RoleAnnotations: no<br>Safe: no<br>StandaloneDeriving: yes<br>StaticPointers: no<br>Strict: no<br>StrictData: no<br>TemplateHaskell: no<br>TemplateHaskellQuotes: no<br>Trustworthy: no</div><div dir="ltr">TupleSections: yes<br>TypeApplications: yes<br>TypeFamilies: yes<br>TypeFamilyDependencies: no<br>TypeOperators: yes<br>TypeSynonymInstances: yes<br>UnboxedSums: no<br>UnboxedTuples: no<br>UndecidableInstances: no<br>UndecidableSuperClasses: no<br>Unsafe: no<br>ViewPatterns: yes</div>
</div>
</body></html>