GHC 2020 standard - Haskell

https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020

Not having to write out these in .cabal by hand would be sooo nice

lists seems kind of arbitrary and contains some stuff that the community at large seems to not like too much/be unsure about

e.g. RecordWildCards ImplicitParams

and for me enabling Overloaded{Strings,Lists} by default is definitely not a great idea, very often I get type ambiguity errors after doing so (more so with Lists, because of Foldable)

you can still opt not to use e.g. ImplicitParams, but enabling it by default is like the compiler is saying to you "we encourage this"

don't know why this isn't a pull request like the other proposals so we can comment on it.. :thinking:

Georgi Lyubenov // googleson78 said:

and for me enabling Overloaded{Strings,Lists} by default is definitely not a great idea, very often I get type ambiguity errors after doing so (more so with Lists, because of Foldable)

the list says they aren't going to be in it

well it says that Eisenberg is against including them, not that they will definitely not be in

my issue is that I (and whoever else wants to) can't write a comment under the linked list with what I just wrote here (and there is also no provided way to express an opinion in the linked list - the best I can do is read through the list and see a mailing list mentioned, and start guessing which mailing list that is)

well then again, if there was some such way I guess this GHC2020 thing would never actually be agreed upon :grinning_face_with_smiling_eyes:

maybe it's going to be opened for discussion later

@Georgi Lyubenov // googleson78 see thread on mailing list and it's continuation in September

From discussion on committee's mailing list:

Applying the actual quota of ⅔ out of 11, i.e. 8 votes, these would go
in no matter how Cale and Eric vote:

BangPatterns, BinaryLiterals, ConstraintKinds, DeriveDataTypeable,
DeriveFoldable, DeriveFunctor, DeriveGeneric, DeriveLift,
DeriveTraversable, EmptyCase, EmptyDataDecls, EmptyDataDeriving,
ExplicitForAll, FlexibleContexts, FlexibleInstances, GADTSyntax,
HexFloatLiterals, ImportQualifiedPost, KindSignatures,
MultiParamTypeClasses, NamedFieldPuns, NumericUnderscores,
StandaloneDeriving, ViewPatterns

The following have 6 or 7 votes, i.e. they’d go in if we extrapolate
from the current votes:

ConstrainedClassMethods, DerivingStrategies,
ExistentialQuantification, GeneralisedNewtypeDeriving, InstanceSigs,
NegativeLiterals, PostfixOperators, RankNTypes, RecordWildCards,
ScopedTypeVariables, TupleSections, TypeApplications, TypeFamilies,
TypeOperators, TypeSynonymInstances

These extensions are short one vote:

DataKinds, DerivingVia, GADTs, LambdaCase, PolyKinds

what

how did LambdaCase not unanimously make it

ditto

yet RecordWildCards has a chance to do so

There's this new proposal for \of that makes committee feel uneasy about including it

ugh

then if it doesn't make it i'd hope \of gets in faster :)

ImportQualifiedPost is in? :joy: awesome. Strange that NumDecimals doesn't appear anywhere though.

@Georgi Lyubenov // googleson78 Personally I don't mind that much - I'm happy that my wall of extensions in .cabal is going to reduce maybe in less than third, and I mean, we're probably going to get newer versions of GHCXXXX extension in upcoming years that will figure the remaining stuff out

RecordWildCards reduces local reasonability, makes code harder to read and bugs easier to creep in. Just imagine what a nightmare it will be for users of NoFieldSelectors. Changing some data type's record fields might cause a bug (not a type error) in a function hundreds of lines away. And all of this just to save you from writing a few words compared to NamedFieldPuns.

when can it cause a bug? I know it can cause a compile error, but I'm not sure when it can cause a bug, when you have -Wall enabled

I guess bugs coming from shadowing, or missing fields - though -Wall seems to be enough to point these out

I wouldn't call anything a bug that's caught by -Wall!

Yeah - honestly I treat lack of -Wall as "debug mode" in my projects - I don't feel comfortable pushing stuff with warnings in general

I also only put -Wno-all in pragmas and have it globally enabled

-Wall isn't even enough, there's some really good warnings that are not included there; I go a different route: -Weverything and exclude the silly ones

huh, hadn't known about that!

I only explicitly activate -Wredundant-constraints

(though it doesn't help perfectly if you're using Polysemy :sweat_smile: )

This is my warnings section. Not perfect, but might be a good place to start:

  - -Weverything
  - -Wno-missing-home-modules # Behavior doesn't make sense
  - -Wno-redundant-constraints # doesn't play nice with DB or other constraint synonyms
  - -Wno-missed-specialisations # brings up a lot more than you'd expect. not sure how actionable they are.
  - -Wno-all-missed-specialisations # see -Wno-missed-specialisations
  - -Wno-unsafe # Don't use Safe Haskell warnings
  - -Wno-safe # Don't use Safe Haskell warnings
  - -Wno-monomorphism-restriction # Don't warn if the monomorphism restriction is used
  - -Wno-missing-safe-haskell-mode

definitely! the incomplete binds, "noop" conversions, no deriving strategies are all great warnings that aren't in Wall