I've taken a look at the SchemaImpl::find case, and I think the new instantiation may indeed be necessary. At least based on that one case, I have no objection to leaving the new instantiations in. One of two things may have changed to trigger the break:
1. One of the methods in afw::table that calls it is inlineable (it's a one-liner defined in Schema.h). If the compiler is now choosing to inline that in code that calls it in meas_algorithms, it could appear that meas_algorithms needs access to the implementation, which is only present in Schema.cc in afw.
2. However, the implementation in Schema.cc in afw is definitely always instantiated, even though it wasn't previously explicitly instantiated: it's called by another function in the same file which is explicitly instantiated. All the google searches I've tried on this subject result in answers to simpler questions, but my understanding is that the standard is silent on whether implicit template instantiations in one library must be available to another library, which is what we'd then be relying on here. In any case, GCC's page on how it handles cross-library template instantiations says that their implementation model (the "Borland model") isn't the only one, and it sounds like behavior might be different under the other model. If this is what changed in Clang's behavior, that's potentially more problematic, as I think we rely on this trick (relying on one explicit instantiation to instantiate something else implicitly) in other places, and we could be seeing mysterious new linker errors for a while as we write new code that relies on things we haven't truly explicitly instantiated. The good news is that the areas where I've seen us use this trick the most are in the plugin framework in meas_algorithms and the Formatters, and those are already slated for replacement.
Bug
I've taken a look at the SchemaImpl::find case, and I think the new instantiation may indeed be necessary. At least based on that one case, I have no objection to leaving the new instantiations in. One of two things may have changed to trigger the break:
1. One of the methods in afw::table that calls it is inlineable (it's a one-liner defined in Schema.h). If the compiler is now choosing to inline that in code that calls it in meas_algorithms, it could appear that meas_algorithms needs access to the implementation, which is only present in Schema.cc in afw.
2. However, the implementation in Schema.cc in afw is definitely always instantiated, even though it wasn't previously explicitly instantiated: it's called by another function in the same file which is explicitly instantiated. All the google searches I've tried on this subject result in answers to simpler questions, but my understanding is that the standard is silent on whether implicit template instantiations in one library must be available to another library, which is what we'd then be relying on here. In any case, GCC's page on how it handles cross-library template instantiations says that their implementation model (the "Borland model") isn't the only one, and it sounds like behavior might be different under the other model. If this is what changed in Clang's behavior, that's potentially more problematic, as I think we rely on this trick (relying on one explicit instantiation to instantiate something else implicitly) in other places, and we could be seeing mysterious new linker errors for a while as we write new code that relies on things we haven't truly explicitly instantiated. The good news is that the areas where I've seen us use this trick the most are in the plugin framework in meas_algorithms and the Formatters, and those are already slated for replacement.