Docs: "Shared" keyword documentation says nothing about methods & constructors.

[ericmutta]

The docs on the Shared keyword don't talk about the behaviour of Shared when applied to methods and constructors. At the end of the article there's a link to the Sub where I was hoping to find information on Shared Sub, but that article just links back to the Shared keyword article.

Is there any article describing the behaviour of shared/static members in the VB docs? If there's, it should be linked it, if there isn't, then we need to expand the article on the Shared keyword to include that information.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 1a7eed7e-92ba-239a-8162-591b666ad6ab
• Version Independent ID: 04d245fd-2a6a-725d-9b86-8e50998afdc3
• Content: Shared (Visual Basic)
• Content Source: docs/visual-basic/language-reference/modifiers/shared.md
• Product: dotnet-visualbasic
• GitHub Login: @KathleenDollard
• Microsoft Alias: kdollard

[KathleenDollard]

Can you give some bullet points about what you think is missing?

[ericmutta]

Here are a couple of behaviors that could be documented:

1. You can't access instance members from a shared method (even though the opposite, accessing a shared member from an instance method, is possible).

2. Even though the docs say you access the shared member by using the class name, VB allows you to access the shared member without specifying the class name (and there's even an IDE analyzer that suggests this as a "simplification").

3. When you make a constructor shared, it runs once for the entire execution of the program, not once per instance created like ordinary constructors.

4. A couple of rules about shared constructors such as the fact that they can't have a visibility modifier (so Public Shared Sub New() is an error) or take parameters.

Those are a few off the top of my head, I reckon there's more and I wasn't able to see the behaviors spelled out explicitly.

[KathleenDollard]

@ericmutta Great points.

There's two ways we can go forward. Docs are open source so that we get the perspectives of people using them, and it greatly improves the docs. My first choice is to have you edit the doc, or propose additional pages if you think something like the constructor deserves that. Myself and either @mairaw or @rpetrusha would help with editing and formatting.

You'd start by just selecting edit pencil in the upper right. Then the process creates a PR for review and merging.

Interested?

[ericmutta]

Interested?

Sure thing! I have done a few PRs on the docs side and had a great experience with both @mairaw and @rpetrusha so I will put this on my to-do list and add some of those points to the Behaviours section :+1:

PS: @mairaw or @rpetrusha are you also monitoring PRs for the donet-api-docs repo? I've had an open PR there for over a month now!

[mairaw]

I see that @rpetrusha took care of that one for you. The two of us have been a bit overwhelmed with the number of PRs on that repo since we have a big push to document .NET Core APIs at the moment, so a few might have fallen through the cracks but we're trying to stay on top of things.

And thank you so much for your contributions! I'll look forward to seeing the PR for this one.

[ericmutta]

@mairaw: The two of us have been a bit overwhelmed...

No worries, I totally understand and wish to extend my thanks to you and the rest of the docs team for the great work you are doing!

[ericmutta]

Can this issue be assigned to me so I can work on it when I get a chance?

[rpetrusha]

I've assigned it to you, @ericmutta. Thanks for volunteering to work on it.