Hi Steve,
Thanks again for your reply. Our types are indeed typedefs of templates, just like the engine handles it’s core types. Adding IsCoreType is required for us on the USTRUCT() in order to compile, otherwise the forward declare that UHT generates causes a redefinition error. You can see this in the code snippet below.
`// OurTransform.h
template<typename T, typename U>
struct TOurTransform {};
// OurFwd.h
using FOurTransform = TOurTransform<double, int64>;
// OurNoExportTypes.h
USTRUCT(BlueprintType, IsCoreType, NoExport)
struct FOurTransform {};`Because IsCoreType is restricted to only files named “NoExportTypes.h” the above fails to compile without the removal of that restriction (which is on line 77 of UhtScriptStructSpecifiers.cs). If we just try removing IsCoreType from the USTRUCT(), we then get errors when trying to use that type as UHT will forward declare it at the top of its generated file (resulting in a redefinition). You can see this behavior on line 109 of UhtStructProperty.cs. The solution for us is simply to remove the restriction that UHT has for that specifier. The question we have is why that restriction is there in the first place. I assume it was just part of the thought-process at the time the core types were coded for the engine.
It is good to hear that you do not anticipate any issues with removing the UHT restriction on IsCoreType. Our experience so far is that removing the restriction works just fine. If that specifier is to be changed/deprecated in the future, we are happy to handle warnings or incompatibilities at that time. A new specifier that directly specifies the “real type” would indeed be an improvement imo. Our wish is simply that this specifier (or whatever replaces it) be allowed/usable to developers who want to achieve similar behavior for how the engine is able to template and typedef it’s core types while still exposing them to UHT and thus Blueprints.
Thanks,
Blake