1. 38
  1.  

  2. 14

    I just discovered that this can be detected with -Wpartial-fields, which is nice, but not part of -Wall.

    Aaaaargh. Why even bother having a -Wall if it doesn’t have all warnings?

    1. 3

      That’s weird in GCC as well; it has -Wall and -Wextra, where the latter enables warnings not enabled by the former.

      1. 4

        IIRC the rationale is that -Wall enables everything uncontroversial, but the maintainers also wanted to include possibly controversial warnings, without making teams fight and in the end turn off -Wall.

        Put differently, if some teams’ sensible code styles says to do x, then -Wall is indended to not warn about x. Or put differently again, if a new diagnostic couldn’t be added to a compiler because it would make -Wall too loud, then that is added but outside -Wall.

        1. 1

          gcc’s -Wall is rarely extended because many projects use -Werror and -Wall. Adding more warnings to -Wall can break their builds and results in angry messages to the GCC mailing list.

        2. 2

          Agreed! I think -Wall should be named -Wrecommended instead.

          Haskell has -Weverything which really does turn on every warning. Amusingly it enables a warning that’s less strict than another warning, so you have to turn that one off. https://gitlab.haskell.org/ghc/ghc/-/issues/14794

        3. 4

          My main experience with Data.Text is that I have to litter T.pack/T.unpack all over my code in order to glue things together. If it was the standard I would be much happier.

          1. 2

            I use lens which provides isomorphisms. Makes it a lot easier: https://hackage.haskell.org/package/lens-4.16/docs/Data-Text-Lens.html

          2. 3

            I really feel for the Pattern Matching section. Typescript semantics (which, correctly IMO, are much smarter about the blurred value/type line) make it easy to write safe code without having to make a bunch of wrapper types and other type-level drudgery to get what you want.

            If the computer sees a literal, it knows the value! And it should be able to carry that around! I understand that this is, of course, not easy. And I guess this makes type-level stuff undecidable (though I believe there’s sets of extensions that get you there anyways). But there’s some great payoffs to be had when you start going down things like type literals, actual first class type unions (not Either but actual “A | B” and not requiring an unwrap).

            The simple example is “I had a function that could take a number. It can now also take a string”. Refactoring that in Typescript is really easy, cuz you don’t have to modify any callsites (And there’s very little engineering value in going around writing Left everywhere, in this specific case). This isn’t a one-size-fits-all thing, but it’s like a pair of M-size sweatpants. I can squeeze into them just fine for the most part.

            This sort of stuff is hard of course, and trying to execute on these kinds of concepts is probably a really thankless job.

            1. 1

              Wouldn’t that require explicit boxing or inlining (possibly with link-time optimization) whereas using a type class allows for full type erasure?