Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Berrysoft opened this issue May 9, 2018 · 14 comments
Open

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

Berrysoft opened this issue May 9, 2018 · 14 comments
Labels
LDM Reviewed: Rejected LDM has reviewed and rejected

Comments

@Berrysoft
Copy link

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
Copy link
Contributor

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
Copy link

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
Copy link
Author

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
Copy link
Contributor

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

@KathleenDollard KathleenDollard added the LDM Reviewed: Rejected LDM has reviewed and rejected label Aug 1, 2018
@tverweij
Copy link

Solved in project Mercury

@antonfirsov
Copy link
Member

antonfirsov commented Jul 4, 2020

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
Copy link
Author

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
Copy link

fitdev commented Jul 21, 2021

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
Copy link
Author

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
Copy link

fitdev commented Jul 22, 2021

@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
Copy link

@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
Copy link

mrange commented Apr 20, 2022

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
Copy link
Member

antonfirsov commented Oct 12, 2022

@teo-tsirpanis #300 (comment) 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
Copy link
Member

AraHaan commented Dec 8, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
LDM Reviewed: Rejected LDM has reviewed and rejected
Projects
None yet
Development

No branches or pull requests

9 participants