<div dir="ltr"><div>Updated votes</div><div><br></div><div>delta:</div><div>- StandaloneKindSignatures: yes</div><div>- StarIsType: yes</div><div><br></div><div>## Uncontroversial extensions<br><br>BangPatterns: yes<br>BinaryLiterals: yes<br>DataKinds: yes<br>DeriveDataTypeable: yes<br>DeriveGeneric: yes<br>EmptyCase: yes<br>ExistentialQuantification: yes<br>FlexibleContexts: yes<br>FlexibleInstances: yes<br>GADTs: yes<br>GeneralisedNewtypeDeriving: yes<br>LambdaCase: yes<br>MultiParamTypeClasses: yes<br>MultiWayIf: yes<br>NoMonomorphismRestriction: yes<br>OverloadedStrings: yes<br>PatternSynonyms: yes<br>RankNTypes: yes<br>RecordWildCards: yes<br>ScopedTypeVariables: yes<br>StandaloneDeriving: yes<br>TupleSections: yes<br>TypeFamilies: yes<br>TypeSynonymInstances: yes<br>NondecreasingIndentation: yes<br>ConstrainedClassMethods: yes<br>ConstraintKinds: yes<br>DefaultSignatures: yes<br>DeriveFoldable: yes<br>DeriveFunctor: yes<br>DeriveTraversable: yes<br>EmptyDataDecls: yes<br>EmptyDataDeriving: yes<br>HexFloatLiterals: yes<br>ImportQualifiedPost: yes<br>InstanceSigs: yes<br>KindSignatures: yes<br>LiberalTypeSynonyms: yes<br>NamedFieldPuns: yes<br>  (I don't personally like this, but I can't justify having<br>  RecordWildcards but not having this)<br>NegativeLiterals: yes<br>NumDecimals: yes<br>PolyKinds: yes<br>PostfixOperators: yes<br>UnicodeSyntax: yes<br>  (but only the language extension, not the UI changes)<br><br>## Extensions that are implied by others, or are irrelevant:<br><br>GADTSyntax: yes<br>ExplicitForAll: yes<br>MonadFailDesugaring: irrelevant<br>MonoLocalBinds: yes<br><br>## Extensions that are deprecated or exist for legacy reasons:<br><br>DatatypeContexts: no<br>NPlusKPatterns: no<br>CUSKs: no<br>NoPatternGuards: no<br>ForeignFunctionInterface: yes<br>  (already implied by Haskell2010, why do we have this but<br>  NoPatternGuards?)<br>NullaryTypeClasses: no<br>OverlappingInstances: no<br>IncoherentInstances: no<br>TypeInType: no<br><br>## No to extensions that are too new to include in GHC2021:<br><br>QualifiedDo: no<br>LinearTypes: no<br>BlockArguments: no<br>LexicalNegation: no<br>QuantifiedConstraints: no<br>StandaloneKindSignatures: yes<br>  (changed to yes because it's needed to replace CUSKs)<br>StarIsType: yes<br>  (changed to yes following discussion)<br><br>## No to extensions that are opt-in by design:<br><br>ApplicativeDo: no<br>  (can lead to non-deterministic behaviour with non-rule-abiding<br>  Applicative instances)<br>PackageImports: no<br>CPP: no<br>DeriveLift: no<br>  (only makes sense with TemplateHaskell, which is opt-in)<br>TemplateHaskell: no<br>TemplateHaskellQuotes: no<br>QuasiQuotes: no<br>RebindableSyntax: no<br>Safe: no<br>Strict: no<br>StrictData: no<br>Trustworthy: no<br>Unsafe: no<br>ExtendedDefaultRules: no<br>NoImplicitPrelude: no<br><br>## No to unsafe extensions:<br><br>UndecidableInstances: no<br>UndecidableSuperClasses: no<br><br>## No to low-level extensions, not intended to be on by default:<br><br>UnboxedTuples: no<br>UnboxedSums: no<br>MagicHash: no<br>UnliftedFFITypes: no<br>UnliftedNewtypes: no<br>GHCForeignImportPrim: no<br>InterruptibleFFI: no<br><br>## No to record-related extensions<br><br>Records are in flux, let's not do any of this in GHC2021.<br><br>DisambiguateRecordFields: no<br>DuplicateRecordFields: no<br>NoTraditionalRecordSyntax: no<br>OverloadedLabels: no<br><br>## The rest<br><br>That leaves some tricky ones, I'm putting all these as "no" or<br>"maybe"; we could conservatively just say "no" to all of them.<br><br>I'm voting NO on these:<br><br>Arrows: no<br>  (not widely used)<br>ImplicitParams: no<br>  (not widely used; questionable semantics; functionality available<br>  with reflection package)<br>ImpredicativeTypes: no<br>  (I don't think we want this on by default, right?)<br>ParallelListComp: no<br>  (not widely used, most uses are covered by zip)<br>StaticPointers: no<br>  (quite a niche extension, only really useful with Distributed Haskell)<br>TransformListComp: no<br>  (not widely used)<br>ViewPatterns: no<br>  (not widely used, and in my opinion not a good design)<br>DeriveAnyClass: no<br>  (see discussion on the mailing list)<br><br>I'm undecided on these:<br><br>AllowAmbiguousTypes: maybe<br>TypeApplications: maybe<br>CApiFFI: maybe<br>  (harmless, but a bit niche)<br>DerivingVia: maybe<br>  (not very widely-used, quite new)<br>DerivingStrategies: maybe<br>  (not very widely-used, quite new)<br>FunctionalDependencies: maybe<br>  (slightly inclined to "no", given the overlap<br>  with TypeFamilies and the lack of widespread usage)<br>ExplicitNamespaces: maybe<br>  (might change, so defer?)<br>MonadComprehensions: maybe<br>  (does this make error messages worse?)<br>PartialTypeSignatures: maybe<br>NamedWildCards: maybe<br>NumericUnderscores: maybe<br>OverloadedLists: maybe<br>  (impact on error messages?)<br>RecursiveDo: maybe<br>  (but introduced by a keyword so relatively harmless)<br>RoleAnnotations: maybe<br>  (not widely used, but when you need it you need it)<br>TypeFamilyDependencies: maybe<br>  (not widely used, but when you need it you need it)<br>TypeOperators: maybe<br></div></div>