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

[Discussion] VB Runtime Community Extensions #560

Open
gilfusion opened this issue Sep 4, 2020 · 4 comments
Open

[Discussion] VB Runtime Community Extensions #560

gilfusion opened this issue Sep 4, 2020 · 4 comments

Comments

@gilfusion
Copy link

In a number of proposals in the last year, a few of us have responded with something along the lines of, "you could write a function to do that". So that's where I'd like to begin, discussing a community-built library of those functions.

Why

  1. It may be easier to get community involvement writing simple functions that it would be to work on a compiler fork.
  2. VB already includes a runtime library (the Microsoft.VisualBasic namespace) that we could use for inspiration as a starting point.
  3. Much VB's syntax is very function-like. What do type casts look like? CType, DirectCast, and TryCast look like functions. The ternary conditional expression looks like an If function and was probably inspired by the IIf function in the runtime library. The null-coalescing operator looks like an "overload" of that same If function. Array indexing looks like calling functions. In the end, would there be much of a difference between creating a new function and creating a new operator that looks like a function anyway?
  4. Function calls can be optimized to be just as efficient as built-in operators in many cases. The JIT can inline functions under certain circumstances, and we can add <MethodImpl(MethodImplOptions.AggressiveInlining)> to encourage it if we need to. There is also the example of CInt(Fix(...)) which in recent versions of the VB compiler is reduced to a single IL instruction, and it may be easier to convince the Roslyn team to add more such optimizations than it would be to convince them to add new language features.
  5. Originally, my thought would be that, over time, features could migrate from the community extensions to Microsoft.VisualBasic itself (kind of like the relationship between the Windows Community Toolkit and WinUI), but that may not be an option now. If the community does fork the VB compiler though, these extensions could become part of that forked VB implementation.

Who, What, and How

Those are the big questions:

  • Who would be willing to work on this?
  • What sorts of functions, classes, etc. would be worth adding to this? (Who is the intended audience for them?)
  • How would it be distributed (NuGet, VS extensions, project templates, etc.)? How should it be promoted?
  • Could/should we ask for "official" Microsoft assistance on this or should the community go for it on our own?

I'm sure there's more that could be added here, but this may be enough to get the discussion started. (And also, whenever someone wants to reply to another language proposal with "you could write a function for that", they could link back here.)

@Echo-8-ERA
Copy link

Echo-8-ERA commented Sep 5, 2020

So basically an expanded #231?

@gilfusion
Copy link
Author

Yes, #231 is something I think should be a part of it.

Other things I could see possibly going in:

@WalterLederer
Copy link

For distribution we could add to VBNetSnippets or fork it if it's no longer maintained. NuGet maybe overkill for unrelated snippets.

For promotion we could add a link to Awesome-dotnet and with "official" Microsoft assistance to vblang readme here also.

If a proposal here in vblang/issues gets more than 2 rocket smilies this could be a sign to copy this snippet to github.
I can also provide some more code snippets here.

Who is willing to copy the snippets from here to some github or other repository?

@DualBrain
Copy link

I'm experimenting with a project right now which is a (sort of) forked version of the VisualBasic runtime. I'm frustrated by the fact that I have "full access" to the runtime in .NET 5 WinForms, "limited access" in a .NET 5 Console and "basically none" access in a netstandard2.x library to the runtime. So I started wondering what, exactly, is holding things back. I created a new repo called Community.VisualBasic to explore this.

This project isn't really ready for any sort of prime time usage (for example, instead of getting the actual errors when errors occur - most of them will result in "notimplemented" exceptions because the original code was accessing internal resources for these errors... but for my experimenting stage, this isn't an issue).

I also changed the namespace as there are issues that I'm not 100% sure how to manage with regards to:

a) completely swapping out the runtime with this one...
b) somehow "merging" the namespaces/classes between multiple assemblies where collisions are somehow magically dealt with.

For now my focus has been on netstandard2.0 and netstandard2.1 with some testing taking place in .NET 5 console. Furthermore, for functions that "simply will not work outside of winforms", I've removed these for the time being - after doing so, I realized that they could just be marked as "obsolete" or something. My original thinking was that I'd rather know immediately that something is not going to work instead of being hit with a surprise some sort of platform not working exception during runtime.

If you'd like to take a peek and give it a go, please check it out at https://github.com/DualBrain/Community.VisualBasic/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants