Usability improvements in GCC 8

A lot of good stuff, reading C++ errors is like learning an extra language on top of the C++ language, I can&#x27;t wait to try it out.<p>&gt; How do I get at some private field?<p>That one is interesting! I wonder how smart it is.<p>For instance in the following example:<p><pre><code> class foo { public: std::pair&lt;int, int&gt; get_coordinates() const { return std::make_pair(m_x, m_y); } private: int m_x; int m_y; }; void test(foo *ptr) { if (ptr-&gt;m_x &gt;= 3) ;&#x2F;&#x2F; etc } </code></pre> I wonder if the compiler would be able to figure out that m_x is accessible via `ptr-&gt;get_coordinates().first` ?

Ever so once in a while, I see stuff like this, remember my C++ days, and feel excited about trying to write more C++… and then I snap out of it, like remembering why you broke up with an ex-lover in the first place.<p>No, but seriously, this is great stuff, and I am always happy to see gcc get better. The next time I write C++, which I’ll try to do for GNU Octave, I’ll be very grateful for better diagnostics. I already am, since gcc keeps getting better and better.

One improvement I&#x27;d like to see is a simplified error message for mismatched overloaded calls. If you make an overloaded call for which the is no matching conversion or if the conversation is ambiguous the compiler will &quot;helpfully&quot; dump a list of possibly matching overloaded function signatures. The list can be hundreds of lines long. For example, when you try to pipe a class to std::cout that doesn&#x27;t have an std::ostream &amp;operator&lt;&lt;(std::ostream &amp;, const X &amp;).<p>Perhaps instead of dumping the complete function signatures it could show one function signature followed by a list of types accepted as the second parameter. Since the signatures are otherwise the same. Such improvements could also reduce template error spew.

The UX of development tools is such an incredibly fundamental thing to fix.<p>Back in the day it was acceptable to build things without thinking how easy they were to use, indeed being &quot;easy&quot; was somehow a bad thing, like people who used to deride users of Mac OS.<p>The same applies to development tools, you aren&#x27;t dumb if your tool is unhelpful, and if it takes 5 seconds less to see a problem, multiply that by how often that problem is encountered around the world, and you&#x27;re making a significant difference to productivity.<p>Not to mention developer sanity. Why should designers have nice tools and we get tools that hate us?

Fantastic work, I hope this is just the beginning.

Fantastic! My thanks to David Malcolm for this work. I think this will help a lot of people.

These are great investments to make! Keep up the good work!

Awesome GSoC project. Well done.

Making C less of a pain, nice