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