FPakFile public Constructor Inaccessible. Why does VS want to reference the FPakFile private destructor instead?

Hello there,
I am currently trying to load a PakFile from a location on disk during runtime. My current approach is adapting this plugin for UE 4.27.2 :

However, I’m running into a bizarre issue when trying to access FPakFile’s Constructor:

    IPlatformFile * LowerLevel,
    const TCHAR * Filename,
    bool bIsSigned,
    bool bLoadIndex

Whenever I try to access it, it seems like the VS wants to access FPakFile’s private destructor instead, giving me the following error:

In the image below, you can see that there is a publicly available constructor, as well as the private destructor that is getting referenced instead.

I have also attempted to access FPakFile’s constructor in another class outside of the AsyncPackageStreamer plugin, just to see if there was something I was doing wrong when I updated AsyncPackageStreamer.Build.cs, but I found that I got the same error there as well.

Here is how I am attempting to access the constructor:

    // Make sure the Pak file is actually there
    FPakFile PakFile(PakPlatform.Get(), *FilePath, bSigned, true);
    if (!PakFile.IsValid())
        UE_LOG(LogAsyncPackageStreamer, Error, TEXT("Invalid pak file: %s"), *FilePath);
        return false;

Here is PakPlatform’s Declaration:

TSharedPtr<FPakPlatformFile> PakPlatform;

I tried to use the FArchive constructor, just for testing purposes, and got a similarly puzzling error.
Pressing Ctrl+Shift+Space to check the arguments shows this:

I have exact same problem!
Documentation states to use #include “IPlatformFilePak.h”.

My wonderful college at work helped me and he fixed it.
It must be that Unreal updated the pipeline, but also did not documented how
It should be used.

Instead of

FPakFile PakFile(PakPlatformFile, *PakFilePathFull, false);

Should be:

FPakFile* PakFile = new FPakFile(PakPlatformFile, *PakFilePathFull, false)

Then in your ProjectName.Build.cs you need to add “PakFile”

PublicDependencyModuleNames.AddRange(new string[] { "Core", "CoreUObject", "Engine", "InputCore", "UMG", "PakFile" });

If FPakFile destructor is private, it means the engine doesn’t want you to create or destroy them directly. When constructing a class/struct like you did, the destructor is implicitly called at the end of the scope, which is why VS is complaining. Using “new” hides the problem because it allocates the object in memory and you are responsible for destroying it yourself to free memory when you don’t need it anymore (or you are supposed to). In this case, you are never destroying it so it’s basically a memory leak.

After glancing through the API and the plugin code, I see the FPakFile is created “properly” by the Mount() function, which is called right after the part you showed. The Mount() function also checks for validity. I don’t see any reason to check for PAK validity before the Mount() function does it.