Unable to call C# 7.3 method with `unmanaged` type parameter

[Berrysoft]

I wrote a C# function like this:

int SizeOf<T>() 
    where T : unmanaged
{
    return sizeof(T);
}

But when I tried to call this function in a VB project, the compiler threw a BC30649 exception said: ""is an unsupported type What should I do to call this function?

[KathleenDollard]

You are correct. We don't support unmanaged types in Visual Basic, even if the type is used in C#.

I'll be honest here... unmanaged types is not a strong point (as I've spent a lot of my career in VB). I don't think I understand your scenario. You have an unmanaged type in VB that you want to pass to C# to get the size?

[Nukepayload2]

I have a blittable Structure and a size in VB that I want to stackalloc a fixed buffer in c# and get the buffer as Span(Of T). So that I can remove unnecessary heap allocations on the hot paths of my VB codes.

[Berrysoft]

The function I gave is only an example. Actually, I tried to write a Pointer(Of T) structure to wrap a C# pointer for VB. Now I write it without unmanaged, but will appreciate it if you support unmanaged types.😉

[KathleenDollard]

There are no plans for Visual Basic to support variations of unsafe code.

[tverweij]

Solved in project Mercury

[antonfirsov]

An unmanaged type constraint can "leak up" to the public API. In case of ImageSharp: the pixel types have the unmanaged constraint for internal reasons, and the high level Image<TPixel> class is a generic type, where TPixel is constrained as TPixel : unmanaged, IPixel<TPixel>

As a result: even though consumer code is not unsafe or low-level, it's not possible to use generic ImageSharp API-s from VB now.

@KathleenDollard have you considered scenarios like this? Any chance it may change your decision?

[Berrysoft]

Before this issue being solved, I suggest switching to C# now, though it is hard to accept that VB.NET is abandoned by M$.

I wish I'm wrong...

[fitdev]

I second the need to be able to consume C# APIs that have unmanaged constraints on them in VB! This is really important in migration scenarios and general VB-C# interop!

[Berrysoft]

Hey @fitdev , I'm happy to see that there's still someone would like this feature after 3 years. But sadly I have to admit that VB has been abandoned by MS. I have ported some of my projects from VB to C#, and never use VB in new projects any more. It is a painful way, but better than sticking to a language abandoned by its inventor.

I will leave this issue open to mark how MS abandoned their wonderful inventions again and again.

[fitdev]

@Berrysoft Good for you that you were able to port your apps to CS. I completely agree that this is the approach going forward. The problem is it takes time, and in the meantime a small feature like this is really a must. I opened another issue where I suggested that at the least enums could be allowed, as that seems to not require much work to implement.

[teo-tsirpanis]

@Berrysoft if you want to use sizeof on any type without the unmanaged constraint, you can use System.Runtime.CompilerServices.Unsafe.SizeOf. If you are not on .NET Core or .NET 5+, you have to install the System.Runtime.CompilerServices.Unsafe NuGet package.

Don't be afraid of the Unsafe in its name, this class has indeed some super unsafe methods, but SizeOf is safe as outlined in dotnet/runtime#41418.

[mrange]

In order to add some "gravitas" to this issue I recently ran into this when using VB + ImageSharp and was stopped right in my tracks. IMHO the problem is not only that it doesn't work but also that the VB compiler produces error messages that is just confusing

2>C:\code\2_ImageSharp.vb(7,34): error BC32044: Type argument 'Rgba32' does not inherit from or implement the constraint type '?'.
2>C:\code\2_ImageSharp.vb(7,34): error BC30649: '' is an unsupported type.

Type '?' and ''? Perhaps supporting unmanaged types is beyond the scope of VB but could I wish for an improved error message at least that guides me to a solution?

[antonfirsov]

@teo-tsirpanis https://github.com/dotnet/vblang/issues/300#issuecomment-926130290 is not a solution for the problem if the unsafe constraint comes from a 3p API. IMO VB users are less likely to need sizeof in their own logic, but they may want to adapt libraries which modernized their codebase and adapted unmanaged constraints (which doesn't always indicate unsafe code).

[AraHaan]

Not to mention libraries like imagesharp where that constraint leaks into their public API despite the public API not needing it.

But then again, can't they have an internal interface that is hidden from everyone else use it though (and then manually write their own reference assembly code that does not contain said interface) where the ref assembly is then used to compile VB.NET Code? I think that could be an option and then they would have to instruct the compiler to drop in the real imagesharp implementation.