<div dir="ltr"><div>I will also change DeriveAnyClass to no:</div><div><br></div><div><div>## Uncontroversial extensions<br><br>I've been writing code with most of these enabled by default for quite<br>some time now. It saves a lot of LANGUAGE pragmas. Other than<br>RecordWildCards I doubt any of these are controversial.<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<span class="gmail-im"><br>RankNTypes: yes<br>RecordWildCards: yes<br>ScopedTypeVariables: yes<br>StandaloneDeriving: yes<br></span>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</div><div> (but only the language extension, not the UI changes)<br></div><div><br></div><div>## 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: no<br>StarIsType: no<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></div><div>DeriveAnyClass: no<br></div><div> (see discussion on the mailing list)<br></div><div><br></div><div>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</div><div class="gmail-yj6qo gmail-ajU"><div id="gmail-:49w" class="gmail-ajR" tabindex="0"><img class="gmail-ajT" src="https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif"></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 1 Dec 2020 at 08:51, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Am Dienstag, den 01.12.2020, 00:43 -0800 schrieb Alejandro Serrano<br>
Mena:<br>
> Thanks everybody for an illuminating discussion about DeriveAnyClass.<br>
> I was not aware of the dark corners of the extension (and actually,<br>
> now I find it weird that GHC itself suggests that extension!). Here<br>
> are my updated votes<br>
<br>
Noted!<br>
<br>
> apart from a ’No’ to DeriveAnyClass I’ve updated my votes of<br>
> StandaloneKindSignatures and ImportQualifiedPost to ‘Yes’.<br>
<br>
JFTR, you also changed OverloadedLists and OverloadedStrings from maybe<br>
to yes.<br>
<br>
<br>
Cheers,<br>
Joachim<br>
-- <br>
Joachim Breitner<br>
<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
<a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
<br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>