When I have a member function declaration that has a return type of a class that is within the namespace of the owning class, that return type is always fully qualified when using "Implement Method", even though it's unnecessary and the declaration did not fully qualify the type. I'll give you a reproducible example.
Start out with the following files in Visual Studio 2017.
Header File (Test.hpp):
namespace Test
{
class FirstClass
{
};
class SecondClass
{
public:
FirstClass DoAThing();
};
}
Source File (Test.cpp):
#include "Test.hpp"
namespace Test
{
}
Now right-click "DoAThing()" in the header and click "Create Implementation". You get the following in the source file:
#include "Menu.hpp"
namespace Test
{
///////////////////////////////////////////////////////////////////////////////
///
///////////////////////////////////////////////////////////////////////////////
Test::FirstClass SecondClass::DoAThing()
{
}
}
By the way, here is my customized "Create Implementation" template which I altered slightly from the VAX default:
///////////////////////////////////////////////////////////////////////////////
///
///////////////////////////////////////////////////////////////////////////////
$SymbolType$ $SymbolContext$($ParameterList$) $MethodQualifier$
{
$end$$MethodBody$
}
Notice that in the generated implementation in the source file, the return type appears as Test::FirstClass. I want this return type to be FirstClass instead (minus the "Test::"). This is not necessary since the definition of the function is placed inside the "Test" namespace.
I expect that Visual Assist should make it a priority to keep return types identical to how they appear in the declaration. And only if it determines keeping it that way may result in a compiler error (assuming it does this type of introspection), it should try to correct it by qualifying it only as necessary. It especially needs to be smart enough about nested namespaces and only go up as far as needed to resolve the type.
