Add visibility to SymbolInformation

[felixfbecker]

I propose an addition to SymbolInformation that allows an LS to report the visibility (private, protected, public) to the client:

interface SymbolInformation {
  visibility?: Visibility;
}
enum Visibility {
  Private = 1,
  Protected = 2,
  Public = 3
}

A client can choose how he uses that information:

• it could display an icon that indicates a symbol is private
• after getting a list of symbols, it could allow the user to hide/show only public symbols

The same property could get added to CompletionItem.

I think private, protected and public should cover all languages, or are there more modifiers in some languages?

The enum should be structured to allow something like

if (symbol.visibility >= Visibility.Protected) {
  // symbol is at least protected or public
}

[kaloyan-raev]

I think private, protected and public should cover all languages, or are there more modifiers in some languages?

In Java there is package visibility, when there is no access modifier used.

[felixfbecker]

Kaloyan Raev (@kaloyan-raev) what do you think would be best to represent package visibility in the proposal?

[kaloyan-raev]

Like this:

enum Visibility {
  Private = 1,
  Package = 2,
  Protected = 3,
  Public = 4
}

[dpwiz]

Better put "public" first, as it's the base case - other cases are kinds of restricted.

[felixfbecker]

Why does this have the 4.0 milestone? This is not a breaking change

[felixfbecker]

wiz public is the highest visibility, so it should be the highest number.

[dpwiz]

So, the visibility set is closed as no further levels can be added below "Private" and above "Public"? That would be unfortunate for non-Javy languages...

[felixfbecker]

I'm confused, below private and after public is exactly where you could still add further levels. And you can add more levels in major protocol versions. We can also decide to leave more slots open in between. But if you have more visibilities in mind, the time to propose them is now :)

[dpwiz]

I'm confused, below private and after public is exactly where you could still add further levels.

That would ruin the pretty ordering we have here. Adding Whatnot = 5 would break that "public is the highest visibility" rule. Adding Something = -10 would add confusion to enum-styled constants.

But if you have more visibilities in mind, the time to propose them is now :)

I propose leaving some wiggle room for the future additions while keeping confusion to the minimum.

[alexet]

C# has 5 levels of accessibility: https://msdn.microsoft.com/en-us/library/wxh6fsc7.aspx, also in this case the accessibility lattice is not a sub lattice of the integer lattice so you can't do simple integer comparisons to check accessibility.

[ljw1004]

C# either has or is going to get a 6th level of accessibility, 'proternal', accessible only to things that derive from the type AND are in the same assembly. (compare with 'protected internal' which is accessible to things that either derive from the type OR are in the same assembly.)

[ljw1004]

One concern I have is to avoid clutter. Imagine you're writing in a language where almost everything is private, apart from the few methods that are explicitly annotated with the modifier export. What would an Outline view look like then? Would it include a 'private' glyph next to every single entry? Or would it leave the entries unadorned by default, and only stick a 'public glyph next to the ones that have the export modifier?

[felixfbecker]

Up to the client to decide. It could grey it out if it's private, it could show an icon, it could just have checkboxes to filter like "only public". The protocol shouldn't make any UI decisions.