Slashdot Mirror

← Back to Stories (view on slashdot.org)

GCC 8.1 Compiler Introduces Initial C++20 Support (gnu.org)

Posted by EditorDavid on from the what's-GNU? dept.

"Are you tired of your existing compilers? Want fresh new language features and better optimizations?" asks an announcement on the GCC mailing list touting "a major release containing substantial new functionality not available in GCC 7.x or previous GCC releases."

An anonymous reader writes: GNU has released the GCC 8.1 compiler with initial support for the C++20 (C++2A) revision of C++ currently under development. This annual update to the GNU Compiler Collection also comes with many other new features/improvements including but not limited to new ARM CPU support, support for next-generation Intel CPUs, AMD HSA IL, and initial work on Fortran 2018 support.

49 of 90 comments (clear)

  1. I'm getting the feeling... by Anonymous Coward · · Score: 1, Interesting

    ... that gcc has gone "uncool", largely because llvm is where all the hipsters are but also because it's now trying too hard, and worse, that C++ is trying to prove something, only to end up like some sort of perl or something. This doesn't seem to be a recipe for success to me.

    1. Re:I'm getting the feeling... by Anonymous Coward · · Score: 1

      The problem with C is that in order to implement any kind of ADT like linked lists, height balanced trees, you have to rewrite every single manipulation function (insert, delete, reorder) for each and every structure required. The only workaround are C+ macro voodoo.

      C++ fixes this problem with templates. The people who write the specifications for C++ are just getting round to adding all that theoretical concepts written about back in the 1960's. LLVM is where the action is happening now. Everyone can just design their own language and have it transpiled into native assembly language.

    2. Re:I'm getting the feeling... by Tough+Love · · Score: 1

      I'm getting the feeling... ...that you are not a practising c++ dev.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    3. Re:I'm getting the feeling... by Anonymous Coward · · Score: 1

      For me, GCC went from being buggy in version 6 to excellent in version 7.

      I don't think GCC has lost its luster. It's more GNU that has, and thus everything related to it. And that's because the developer-freedom of the richest corporations has replaced the user-freedom of the freeloaders in the mind of many open-sourcers.

    4. Re:I'm getting the feeling... by fred6666 · · Score: 2

      The difference is not the supported languages, but the supported targets.
      The embedded systems, toasters, light bulbs of the world are all developed in a language (usually C, and to a lesser extent C++) compiled using GCC or a derivative. But I've never seen a CPU vendor toolchain based on LLVM. I am sure it exists, but the popular ones are still based on GCC. And I've used various platforms from TI, NXP, Microchip, STmicro, Atheros, Broadcom, etc. All based on GCC.

    5. Re:I'm getting the feeling... by arglebargle_xiv · · Score: 1

      "Are you tired of your existing compilers? Want fresh new language features and better optimizations?"

      "Then consider ditching gcc and going with LLVM". Is that how the quote ends?

      I can't wait for that festing pile of bloat and compiler bugs to finally die, I really can't. Every single new release brings more code-generation bugs that we have to work around in our product, we're slowly working away at The Mgt. to get them to simply require LLVM or some other compiler that doesn't break things on every release, and whose maintainers will actually respond to bug reports rather than closing them all with WONTFIX, "if you squint at the spec from just the right angle and use your imagination then this showstopper bug is actually permitted".

    6. Re:I'm getting the feeling... by religionofpeas · · Score: 1

      Why don't you stick to one release that works ?

    7. Re:I'm getting the feeling... by goose-incarnated · · Score: 1, Insightful

      "Are you tired of your existing compilers? Want fresh new language features and better optimizations?"

      "Then consider ditching gcc and going with LLVM". Is that how the quote ends?

      I can't wait for that festing pile of bloat and compiler bugs to finally die, I really can't. Every single new release brings more code-generation bugs that we have to work around in our product, we're slowly working away at The Mgt. to get them to simply require LLVM or some other compiler that doesn't break things on every release, and whose maintainers will actually respond to bug reports rather than closing them all with WONTFIX, "if you squint at the spec from just the right angle and use your imagination then this showstopper bug is actually permitted".

      I'm calling you a liar on all of those. The biggest difference is that LLVM is trendy and GCC is not.

      very single new release brings more code-generation bugs that we have to work around in our product,

      Example? (I know you don't have an example of consecutive releases with different codegen bugs, but asking at least makes it clear to other readers that you don't know what you are talking about).

      --
      I'm a minority race. Save your vitriol for white people.
    8. Re:I'm getting the feeling... by OolimPhon · · Score: 1

      I can't wait for that festing pile of bloat and compiler bugs to finally die, I really can't. Every single new release brings more code-generation bugs that we have to work around in our product, we're slowly working away at The Mgt. to get them to simply require LLVM or some other compiler that doesn't break things on every release, and whose maintainers will actually respond to bug reports rather than closing them all with WONTFIX, "if you squint at the spec from just the right angle and use your imagination then this showstopper bug is actually permitted".

      Wait, what? Has gcc been taken over by Poettering, now?

    9. Re:I'm getting the feeling... by serviscope_minor · · Score: 1

      "if you squint at the spec from just the right angle and use your imagination then this showstopper bug is actually permitted".

      IOW you're writing noncompliant code and blaming it on compiler bugs.

      All compilers do that whole "squint at the spec from the right angle" because that's how optimizers work. You put in the rules of the spec and the code into a theorem prover and it crunches on it to figure out dead code, aliasing, constants and so on and so forth.

      No one's feeding in perverse interpretations of conflicting rules just to fuck with you. A theorem prover doesn't have human intelligence to decide on the sensibleness of various rules. It crunches blindly, quickly and stupidly.

      --
      SJW n. One who posts facts.
    10. Re:I'm getting the feeling... by arglebargle_xiv · · Score: 2

      I know you don't have an example of consecutive releases with different codegen bugs, but asking at least makes it clear to other readers that you don't know what you are talking about

      Gosh, you know a lot about this, don't you? Which version of gcc would you like the bugs for? There's so many of them I'd have to go for a specific version.

      Incidentally, this code is built using between thirty and fourty different compilers, depending on how you count them (for example are VC++ 6.0, .NET, and the current Visual Studio counted as the same compiler or not? There are at least three different code bases there). gcc has more code generation bugs than every other compiler combined. That's the sum of thirty to forty compilers that have less bugs combined than gcc. Quite an impressive record. It really is an awful compiler to work with.

    11. Re:I'm getting the feeling... by religionofpeas · · Score: 2

      gcc is right and every other compiler out there is wrong?

      No, gcc is right and the other compilers are right too. Your code is wrong.

    12. Re:I'm getting the feeling... by serviscope_minor · · Score: 3, Informative

      C++ is trying to prove something,

      About the only thing it's trying to "prove" is that it can move with the times. And it's proving that by doing so. C++98 was awfully long in the tooth by 2011 in that C++11 provided in many cases better, more efficient, shorter, more obvious and cleaner mechanism for doing a lot of common things.

      Other things have simply proven incerdibly hard ot get right: concepts has been in the works for 30 years!

      This doesn't seem to be a recipe for success to me.

      C++ is already successful, but it won't stay that way without work.

      --
      SJW n. One who posts facts.
    13. Re:I'm getting the feeling... by goose-incarnated · · Score: 3, Interesting

      Gosh, you know a lot about this, don't you?

      As a matter of fact, I do. A lot more than you, at any rate.

      Which version of gcc would you like the bugs for?

      You claimed that every new release of GCC brings more codegen bugs:

      Every single new release brings more code-generation bugs

      So, please, list the codegen bugs you claimed were added between every single release. In other words, for each of the releases listed below, please fill in the new codegen bugs that you found in that release. Since you also claimed that each release has more bugs that the previous one, your list should either grow or contain only bugs that were never fixed in subsequent releases.

      So, here is the list; for each one fill in at least one codegen bug that was introduced in that release:

      GCC 8.1, GCC 7.3, GCC 5.5, GCC 7.2, GCC 6.4, GCC 7.1, GCC 6.3, GCC 6.2, GCC 4.9.4, GCC 5.4, GCC 6.1, GCC 5.3, GCC 5.2, GCC 4.9.3, GCC 4.8.5, GCC 5.1, GCC 4.8.4, GCC 4.9.2, GCC 4.9.1, GCC 4.7.4, GCC 4.8.3, GCC 4.9.0, GCC 4.8.2, GCC 4.8.1, GCC 4.6.4, GCC 4.7.3, GCC 4.8.0, GCC 4.7.2, GCC 4.5.4, GCC 4.7.1, GCC 4.7.0, GCC 4.4.7, GCC 4.6.3, GCC 4.6.2, GCC 4.6.1, GCC 4.3.6, GCC 4.5.3, GCC 4.4.6, GCC 4.6.0, GCC 4.5.2, GCC 4.4.5, GCC 4.5.1, GCC 4.3.5, GCC 4.4.4, GCC 4.5.0, GCC 4.4.3,

      The reason I know that you don't know wht you're talking about is because I actually follow the issues on some of the gcc mailing lists, especially the codegen bugs.

      If you don't know what you are doing when using GCC, you're not suddenly going to become competent by switching to LLVM.

      You made the claim, now provide the evidence. Consider it an opportunity to show off how well you know your toolchains.

      for example are VC++ 6.0, .NET, and the current Visual Studio

      Even better, since you're on VC++, let's limit the codegen bugs to those targets that are supported by VC++ too. After all, you can't have been inconvenienced by bugs on a platform you don't use.

      I shall be sure to quote this thread back at you every opportunity I get.

      --
      I'm a minority race. Save your vitriol for white people.
    14. Re:I'm getting the feeling... by serviscope_minor · · Score: 2

      Good job on ignoring the part where I explained my reasoning.

      You're a gcc maintainer I assume?

      Nope, I'm a happy user of GCC.

      That's one of their main comebacks, "your code is noncompliant and it's not our compiler that's broken".

      Yep, and they're correct.

      Funny thing is, the thirty to forty other compilers that the same code is built with (see my other comment above) all work fine, it's only gcc that generates invalid code. Odd that, isn't it, that gcc is right and every other compiler out there is wrong?

      GCC has better optimizations than the vast majority of those 30-40 compilers. Clang is almost as good and almost as pedantic with the standard now.

      Oh, right, but it's noncompliant code, not a gcc bug. Closed, WONTFIX.

      Precisely. How the fuck are the GCC maintainers meant to read your mind and know what you meant when you wrote noncompliant code?

      --
      SJW n. One who posts facts.
    15. Re:I'm getting the feeling... by Ed+Avis · · Score: 2

      Sometimes I wish that if the optimizer finds something really juicy (like eliminating a dozen lines of code because it can prove they will never be called by assuming that undefined behaviour won't be triggered) it would just refrain from optimizing the code out and instead emit a diagnostic telling the programmer to apply that optimization in the source code. You could then review the code and either say 'gee, the compiler is right, I will delete that whole branch', or 'ouch, that should not be happening... let me find where I am relying on undefined behaviour', or in some cases add an explicit compiler hint to allow the optimizer to take an axe to the code without bothering you further. It would have to be a heuristic, and would produce some false positives (where the optimizer is fine, and should just do its job without chatter), but in the cases it did work it would avoid a lot of acrimony and language-lawyering.

      --
      -- Ed Avis ed@membled.com
    16. Re:I'm getting the feeling... by JesseMcDonald · · Score: 1

      emit a diagnostic telling the programmer to apply that optimization in the source code

      It usually isn't that simple. The obvious source-level optimizations you're describing are relatively rare; the ones which lead to major size and performance improvements come about when you combine generic code in inlined functions and macros—often from distinct source modules, perhaps even different projects—with the results of prior optimizations. To apply these optimizations at the source level you would need to specialize the definitions for each use case.

      --
      "The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
    17. Re:I'm getting the feeling... by tlhIngan · · Score: 1

      ... that gcc has gone "uncool", largely because llvm is where all the hipsters are but also because it's now trying too hard, and worse, that C++ is trying to prove something, only to end up like some sort of perl or something. This doesn't seem to be a recipe for success to me.

      No, everyone moved to LLVM because for a long time, GCC development basically stalled. It was "good enough" and everyone put up with it. DIdn't like it, just put up with it.

      Then LLVM came about and that spurred on a flurry of development - it was modern, it was complete, it was useful. There were clear advantages at the time to using LLVM - the compiler gave better error messages and better warnings. And it started supporting modern language features.

      This forced the GCC developers to kick up development because GCC was getting rather tired and lacking. This has resulted in GCC improving in leaps and bounds and becoming far less crusty and more modern.

      For a long time everyone stuck with GCC 2.95 for everything as it generally worked and was the stable version for many platforms and architectures. The past decade with LLVM has brought so much more to the table and GCC was forced to adapt and proceed beyond 2.95 and produce releases that made significant improvements.

      I'd say what happened was LLVM exposed just how old and tired GCC was (something everyone knew but couldn't spur development on) and GCC was forced to shape up. It still has issues, but at least it's up to date these days.

  2. Here lies C++, killed by feature creep by Anonymous Coward · · Score: 1, Insightful

    Recent features: [=, this] as a lambda capture, Template parameter lists on lambdas, three-way comparison using the "spaceship operator", operator

    C++ had Frankenstein's Monster syndrome back when STL started, and the generated templates were near impossible to debug. K&R complained C had too many operators. Here they are adding more and more. Step back from the keyboard and let the language be.

    1. Re:Here lies C++, killed by feature creep by religionofpeas · · Score: 2

      All those extra operators idioms like "+=" and "++" were inherited from its predecessor B** (well actually, adapted from "=+" because of the lexical ambiguity) to match accumulator style instructions common in contemporary instruction sets and to reduce compiler complexity

      The first compiler was made on a PDP-7 that didn't even have increment instructions.

      The += operator is useful on any platform, simply because it saves you from writing (and reading) the same expression twice.

    2. Re:Here lies C++, killed by feature creep by sjames · · Score: 1

      But for long after that, in simple C compilers, ++ would use INC if it was available while +=1 and a=a+1 would generate multiple instructions or use ADD immediate (and so take more cycles to execute).

      Of course these days, optimization is better and the different forms will produce the same instructions.

    3. Re:Here lies C++, killed by feature creep by religionofpeas · · Score: 2

      But for long after that, in simple C compilers, ++ would use INC if it was available while +=1 and a=a+1 would generate multiple instructions or use ADD immediate (and so take more cycles to execute).

      Maybe, but that has nothing to do with the reason they are in the language. Also, I doubt many compilers worked that way (can you name one ?). If I had to write a compiler, the first step would be to generate an abstract syntax tree, where a++, a+= 1 and a = a + 1, would all be represented as assign(a, add(a, 1)). Choosing between inc/add would be done at the code generation phase.

    4. Re:Here lies C++, killed by feature creep by serviscope_minor · · Score: 1

      Recent features: [=, this] as a lambda capture, Template parameter lists on lambdas,

      What's wrong with those? The parameter lists just make lambdas work and act more like all other functions rather than being a special case.

      Here they are adding more and more. Step back from the keyboard and let the language be.

      No thanks. The world moves on. It turns out there have been developments in programming since the early 1970s and I'd rather be able to use them rather than micromanage eveyr aspect of the compiler.

      The main thing C has going for it for general purpose code these days is the absurd degree of fetishisation it has in the open source community.

      --
      SJW n. One who posts facts.
    5. Re:Here lies C++, killed by feature creep by sjames · · Score: 1

      It has been decades, but IIRC, MSC and Borland in their earlier versions (and so, also Lattice C).

      Keep in mind, this was when you could significantly speed up a program by choosing well what variables to declare as register since the compiler didn't know.

    6. Re:Here lies C++, killed by feature creep by peppepz · · Score: 1

      A buffer overflow is one thing, they can cause bad things to happen, but you really don't want your ABS to throw an exception or start the garbage collector at the wrong time.

      And what would you want it to do? Return a nonsensical result and keep the program going on without detecting the fault? In the past many safety-critical applications were coded in Ada because of the language's safety-oriented design, which included exceptions.

    7. Re:Here lies C++, killed by feature creep by K.+S.+Kyosuke · · Score: 1

      Template parameter lists on lambdas

      Ah, the M:N feature interaction problem... And the reason I really like simple languages.

      --
      Ezekiel 23:20
    8. Re:Here lies C++, killed by feature creep by K.+S.+Kyosuke · · Score: 1

      TeX isn't semantic - hell, it's not just that, it isn't even parseable without a full TeX implementation - and nobody forces you to write MathML by hand.

      --
      Ezekiel 23:20
    9. Re:Here lies C++, killed by feature creep by K.+S.+Kyosuke · · Score: 1

      Ah, that should have been M:M, obviously.

      --
      Ezekiel 23:20
  3. Designated Initializers by Tough+Love · · Score: 2

    Cowabunga! This fixes the single most vexing upward compatibility issue between C and C++, and also a glaring maintainability issue in C++. How sweet that it only took, hmm, two decades to work through the initialization order wankery. Note: gcc has had this since forever, but disabled because the standard org didn't bless it.

    --
    When all you have is a hammer, every problem starts to look like a thumb.
    1. Re:Designated Initializers by Tough+Love · · Score: 1

      Comprehension comes from reading.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
  4. modules by Anonymous Coward · · Score: 1

    the only new feature that really matters

  5. “Are you tired of your existing compilers?&r by 93+Escort+Wagon · · Score: 4, Insightful

    Isn’t that why people left gcc for clang/llvm in the first place?

    --
    #DeleteChrome
  6. Re:Future migration from weak C. by Anonymous Coward · · Score: 1

    You forgot to say that your language also has hookers and blackjack.

  7. Wrong. by Gravis+Zero · · Score: 1

    I'm getting the feeling that gcc has gone "uncool", largely because llvm is where all the hipsters are but also because it's now trying too hard

    And here I thought it was because GCC is an unwieldy monster that uses an abundance of proprietary macros, compiler extensions and only recently allowed C++ on a limited basis. Silly me.

    --
    Anons need not reply. Questions end with a question mark.
    1. Re:Wrong. by religionofpeas · · Score: 1

      I use gcc every single day, mostly for embedded work, and I'm quite happy with the results. Maybe inside it's an unwieldy monster, but I don't have to look at that, so it doesn't bother me. I even use some the compiler extensions, as they are quite useful for my job.

  8. Are you tired of your existing compilers? by jbn-o · · Score: 3, Insightful

    In the case of Apple and Qualcomm, they apparently prefer a compiler that will let them distribute a proprietary (non-free, user-subjugating) derivative. Brad Kuhn, President of Software Freedom Conservancy, has predicted that as soon as Apple finds the compiler to be good enough they'll stop their upstream contributions.

    --
    Digital Citizen
    1. Re:Are you tired of your existing compilers? by Dog-Cow · · Score: 1

      as soon as Apple finds the compiler to be good enough they'll stop their upstream contributions.

      So... never?

    2. Re:Are you tired of your existing compilers? by 93+Escort+Wagon · · Score: 2

      In the case of Apple and Qualcomm, they apparently prefer a compiler that will let them distribute a proprietary (non-free, user-subjugating) derivative.

      Okay, and how about FreeBSD and OpenBSD - and, since you called out Apple, how about Android? They've all moved to Clang.

      I guess not everyone is sufficiently adherent to The One True Faith.

      --
      #DeleteChrome
    3. Re:Are you tired of your existing compilers? by jbn-o · · Score: 2, Interesting

      Your namecalling notwithstanding, Brad Kuhn has already covered this as well and there's nothing particularly special about the examples you list. Apple certainly stands out because of Apple's irrational hatred of being a GPL licensee (which dates back to how NeXT treated NeXT OS users with their Objective-C additions to GCC, referenced in Copyleft: Pragmatic Idealism). Kuhn pointed out something that might be the case now: there are non-free add-ons for that compiler. As these add-ons gain popularity developers become dependent on their functionality. Kuhn has said that there could come a time when such dependence means that practical use of that compiler will almost require using these non-free add-ons as well. This means spreading more software non-freedom to more computer users. I imagine that won't be much of a problem for any OS that accepts non-free software (say by distributing non-free kernel modules, or encouraging users to install non-free applications) because such choices indicate they've already chosen to become dependent on non-free software.

      --
      Digital Citizen
    4. Re:Are you tired of your existing compilers? by arglebargle_xiv · · Score: 2

      In the case of Apple and Qualcomm, they apparently prefer a compiler that will let them distribute a proprietary (non-free, user-subjugating) derivative.

      I prefer a compiler that generates efficient, error-free code, and that's it. I'll leave focusing on the ideological wankery to the SJWs.

    5. Re:Are you tired of your existing compilers? by sjames · · Score: 2

      That "ideological wankery" is why so many kids can afford access to mainstream professional development tools today. The kids in the '70s and early '80s didn't use BASIC because they thought it was the best choice, they did it because a decent professional grade C compiler cost hundreds of dollars (close to a thousand in today's dollars)

      What you call wankery, I call simple practicality. Why would I want to tie the future of my software to the "good will" of a proprietary vendor?

    6. Re:Are you tired of your existing compilers? by religionofpeas · · Score: 1

      The kids in the '70s and early '80s didn't use BASIC because they thought it was the best choice, they did it because a decent professional grade C compiler cost hundreds of dollars (close to a thousand in today's dollars)

      I thought it was because I was running a 6502 with 12kB of memory and cassette tapes.

    7. Re:Are you tired of your existing compilers? by tlhIngan · · Score: 2

      In the case of Apple and Qualcomm, they apparently prefer a compiler that will let them distribute a proprietary (non-free, user-subjugating) derivative. Brad Kuhn, President of Software Freedom Conservancy, has predicted that as soon as Apple finds the compiler to be good enough they'll stop their upstream contributions.

      Well, several reasons. First was GPLv3 which most companies are extremely wary of. Apple began investment in LLVM long before GCC went GPLv3 - LLVM was available as a limited functionality toolchain since OS X 10.3 or so. I think Apple fully switched a year or two after GCC made the switch.

      The second reason is code duplication - GCC is intentionally hard to modularize - generally decided as a way to enforce the GPL. Apple and XCode needed modularity so they could neat tricks like in-place compilation (the compiler regenerates the code as you fix the error), as well as syntax error highlighting (it finds an error as you make it).

      Since Apple was effectively rewriting a front end compiler for these functions, they contributed that to make CLang, as well as using bits and pieces of LLVM since it was much easier to integrate.

      One side effect is the standardization of compilers - before LLVM, everyone had their own compilers, all with varying stages of compatibility for code. Nowadays, it seems everyone has abandoned their own compilers and standardized on LLVM, with interesting effects. It's done interesting things including having final compilation postponed until runtime where you can take the IR bytecode and then use it to target either the main CPU, GPU, DSP or other accelerator at runtime.

      Another thing is drivers often need to compile code at runtime. Instead of everyone having crappy compilers (and having to be driver-version-dependent because some versions come with lame compilers), you have drivers with generally good compilers.

      Toolchain quality has gone up significantly the past few years

    8. Re:Are you tired of your existing compilers? by Anonymous Coward · · Score: 1

      they apparently prefer a compiler that will let them distribute a proprietary (non-free, user-subjugating) derivative.

      Worse clang can be integrated with an IDE ( refactoring, syntax highlighting, autocompletion, ... ), somthing gcc can't and never will support. IDEs that offer these features for C++ either have to rely on incomplete hacks or simply use functionality provided by clang. Last time someone tried to write refactoring with official gcc support for emacs he got stalled by RMS for over a year before it was effectively killed - RMS "planned" to look into a possible solution, none ever surfaced.

    9. Re:Are you tired of your existing compilers? by sjames · · Score: 1

      That's why you did it, but the Apple ][, PET, VIC-20, and C64 could have managed it if expanded from the base models. Certainly, the old IBM-PC (or the many clones) could handle a C compiler, but it was a few years before anything like a useful proprietary C compiler became somewhat affordable.

      Keep in mind, the PDP-7 wasn't that much more capable.

    10. Re:Are you tired of your existing compilers? by sjames · · Score: 1

      The Vic-20 came out before there was a C64. So some people did expand their existing Vic. I also saw one with the ROMs swapped out for a FORTH system.

      I said early '80s exactly because Borland did make having a C compiler more affordable. Of course, at that time it was seen as more of a beginner's compiler than pro grade (even if it was in many ways superior to MSC).

  9. Originally Fortran 2015... by slew · · Score: 1

    They are running a little late...

  10. Maybe not by Kormoran · · Score: 1

    "From: Jakub Jelinek : GCC 8.1 Released

    Some code that compiled successfully with older GCC versions might require
    source changes"

    OK I'll stick to my version, I think...

    1. Re:Maybe not by rl117 · · Score: 2

      It's no different to any previous compiler release by any vendor. Any new version may increase the strictness, and if you read the list of extra checks the compiler is doing, they are all entirely reasonable and in most cases only affect buggy code which would misbehave and already needed fixing. Bring on the extra strictness and improve the quality of your codebases, I say.