Requiring a reference implementation with a standard is a bad idea. First off, who's going to write it? The compiler vendors are the people who'd likely do the best job, and they already have to adapt their implementations for changes--now you're making them do it twice. Another, even bigger issue, is that it actually doesn't tell you what's hard to implement. MSVC, gcc, and clang all take different approaches to their compiler, and what can be easy to implement in one could turn out to be ridiculously difficult in another (e.g., exposing a full AST via reflective mechanisms). You need a diversity of implementations, not just one implementation, to know what's actually hard to implement and what's not.
It's interesting that you bring up export templates, because that fiasco feature actually already sort of had a reference implementation. The original Cfront compiler actually supported it (admittedly, it was very buggy). The problem with export was that, at the time of discussion (~1996), no one really understood just what the impact of all of the template complexity meant--they assumed that templates were basically just a typesafe variant of the C preprocessor (or at least that most common use could be boiled down to that description; its Turing-completeness was known by then).
So, in that vein, export template was seen as a "well, this is going to be tricky, but so is name resolution in general in C++" and the overarching use case was compelling (you can hide the implementation of a regular function, why not templates?). Compiler vendors objected to the feature, but not on the basis that it was essentially impossible to implement, but rather that major design points would need quibbles. It was eventually accepted into the standard largely with the understanding that everyone would implement something close to it, if not the exact current specification.
The only thing that would have prevented export template from being standardized would have been requiring a fairly robust implementation that could have discovered that export template really did infect every part of the code base in a horrible way, and it should be noted that reference implementations generally aren't that robust. Amaya, after all, didn't prevent HTML 4 or CSS 2 from having unimplementable sections.
> The original Cfront compiler actually supported it (admittedly, it was very buggy). The problem with export was that, at the time of discussion (~1996), no one really understood just what the impact of all of the template complexity
Actually I think they kind of did, as Ada already had generics and modules in 1983. And STL was born on Ada.
However, Ada compilers were once upon a time believed to be complexer to implement than C++ ones and had beefy hardware requirements, so maybe they didn't want to try that route.
> Amaya, after all, didn't prevent HTML 4 or CSS 2 from having unimplementable sections.
Amaya was always in an odd place — it was a "testbed" and not a reference implementation. (Also, if you actually look at the parts HTML 4 that required anyone to do anything, you end up with things like dbaron's table (as in, a desk) implementation of it: put quotations mark at either end of the table, and whatever HTML you put on the table, it has fulfilled all the requirements of the standard.)
But yes, the underlying problem of different approaches is a large part of the reason why you want multiple implementations — the other large part is you want evidence the standard is clear enough to lead to interoperable implementations. These are the two big reasons the W3C now require evidence of two, distinct, interoperable implementations of a specification to proceed down the Recommendation track beyond Candidate Recommendation (i.e., to Proposed Recommendation)… and this is the reason why so much around the W3C takes so long, because people by and large don't want to fix ancient, obscure bugs which are often time-consuming to fix for the sake of the standard progressing.
It's interesting that you bring up export templates, because that fiasco feature actually already sort of had a reference implementation. The original Cfront compiler actually supported it (admittedly, it was very buggy). The problem with export was that, at the time of discussion (~1996), no one really understood just what the impact of all of the template complexity meant--they assumed that templates were basically just a typesafe variant of the C preprocessor (or at least that most common use could be boiled down to that description; its Turing-completeness was known by then).
So, in that vein, export template was seen as a "well, this is going to be tricky, but so is name resolution in general in C++" and the overarching use case was compelling (you can hide the implementation of a regular function, why not templates?). Compiler vendors objected to the feature, but not on the basis that it was essentially impossible to implement, but rather that major design points would need quibbles. It was eventually accepted into the standard largely with the understanding that everyone would implement something close to it, if not the exact current specification.
The only thing that would have prevented export template from being standardized would have been requiring a fairly robust implementation that could have discovered that export template really did infect every part of the code base in a horrible way, and it should be noted that reference implementations generally aren't that robust. Amaya, after all, didn't prevent HTML 4 or CSS 2 from having unimplementable sections.