dotnet / dotnet/vblang

Support unmanaged generic constraint for interop with C#

Open
#604 1 comment 2 reactions 0 assignees View on GitHub
Dominant language
No language data
Stars
328
Forks
71
PR merge metrics
No merged PRs in 30d

Description

I have seen a few issue related to this from 2-3 years ago, however they seem to be closed. I am bringing this up again, because I feel like there is an even greater need for this now, in 2021, than in the past for the following reasons:

- C# 10 will soon be released, whereas the `unmanaged` constraint was introduced in 7.3, and so by now this is a pretty well known feature of the language and more and more APIs are/will be using it in their public surface.
- As .Net (Core) matures with version 6 and beyond, considering that VB is not really evolving, and all the coolest runtime-related features are being implemented in/fro C#, - this will drive the migration from VB to C# even more (people do want to take advantage of the new features in the runtime). As part of this process, the need for interop with C# will be great, and the lack of `unmanaged` constraint support is a serious stumbling block (as is in my case for example).

At the very least, you should consider treating all `Enum`s in VB as valid for `unmanaged` constraint. That is: it will be already a big step if you just enable it for enums, and it likely ahrdly requires any work, since VB compiler already knows which types are enums and which aren't (no need for more complex logic to determine if the type is unmanaged).

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.