Is there a way to force creation of F# type aliases as actual types in the MSIL?

Viewed 288

I am working on taking a bunch of functionality out of a large F# library that is used by a lot of downstream code. For reasons too longwinded to explain here, I need to go through the intermediate step of moving the types and modules I'm after to a new separate F# project and a new namespace and creating stubs using type aliases/abbreviations for where they used to be in the old large library, like this: type TypeBeingMoved = New.Namespace.TypeBeingMoved. For modules, I have to be more explicit, actually making such stubs for every function defined in the module (this is a bit tedious, but OK). The idea is that we need to give the current users of the library that is being dismembered a few versions to migrate to using the new smaller library, encouraging them via enforced compiler warnings that we will make the old large library stubs emit -- at least that is the plan.

This works OK for modules, where such stubbing works fine.

The trouble arises because type aliases are deliberately "dropped" during the translation of F# to MSIL -- see https://docs.microsoft.com/en-us/dotnet/articles/fsharp/language-reference/type-abbreviations -- the idea being that you should really be using the type they are pointing to. I would very much like my users to do exactly this, but do unfortunately need to jump through the hoop described above. So as it stands, my users' current code simply stops compiling because replacing a type with an alias/abbreviation that points to another library/namespace results in the type disappearing from the original library's DLL. Is there a way to either force the generation of a type from a type alias/abbreviation, or a way to create such a type stub that would be equivalent to a type alias/abbreviation?

0 Answers
Related