Types are not tagged as types

[matter123]

This is a meta issue similar to #81 but for types.

Progress:

• ✅ in structs/classes/enums/unions
• 🔵 in declarations Improve tagging for variable declarations #71 (see Explore variable declares, func pointers, parameter improvements, and more #135 (comment) which requires Regex features missing readable version #127 and backreferences do not work in start_pattern or end_pattern #163)
• ✅ in parameters function parameter highlighting improvements #134
• ⚪ after new expressions Mark type after new expression as a type #129
• ⚪ initializer/constructor calls
• 🏃‍♂️ in typedefs add highlighting for typedef when used before class/struct/union #191
• ✅ using aliases Add type alias #161
• ✅ in function return types Fix #183 #184
• 🏃 function pointers Add Full support for function pointers #160
• 🔵 inside type casts both C/C++ style and explicit
  • 🔵 C style: (Type)foo
  • ❓ C++ style: Type(foo) is this different than an explicit constructor call? should it be marked differently?
  • 🏃 Explicit static_cast<Type>(foo)
• ✅ following typename in templates. in vector<typename A::B> both A and B are types

Key	Explanation
✅	complete
🏃‍♂️	in progress
⚪	not started
❓	has not been investigated
🔵	blocked (see issue)

[matter123]

@alekseyt Moving the discussion from #198 to here

So v1.9.0 Added support for tagging the return type. This currently causes inconsistencies because variable declarations do not have their type tagged. The current issue with tagging variable declaration types is that in A * B; it is unknown if A * is a type or if A and B are both variables multiplied together.

[alekseyt]

IMO the issue with ambiguity of expression is a big issue, but another issue is that there is no way to remove such inconsistencies or unwanted highlighting. It would be much easier for me personally just to remove highlighting in places where it's inconsistent.

The issue with inconsistency in highlighting is that i depend on it when i'm typing. If i type something and it's highlighted then i assume i typed it correctly without re-reading typed text. If i typed something and it isn't highlighted when i expect it to be highlighted then i need to stop and find a potential typo.

When highlighting is inconsistent then i can't have "muscle memory" for such things and every occurrence of "typo" is effectively false positive so to say. So it's better not to have highlighting at all rather than to have inconsistent highlighting, in general. It doesn't look very good too. This is just my personal opinion, just to explain my way of thinking.

So one way to fix this might be to add tags where they are missing and dive into issues with ambiguity, but another way might be to provide some way to just disable highlighting where it's unwanted, inconsistent or ambiguous.

For example, if std::string would be just no type always without going into entity.name.scope-resolution and other bits, or if something::something() would always be a function call, IMO it would be easier to style it and it could play better with other themes too without the need to tailor them for C++ specifically.

Just saying that instead of making things more complex it might be easier to make things simpler. I don't have a proof of that concept, just an idea. This is an issue for discussion, right?

But ability to style a scope name is a good thing too, i'm not in any way discouraging you from removing liberties from people who do C++ syntax highlighting specifically, it's a good stuff. Although there might not be a lot of people who would prefer to make a theme specifically for C++, it's often necessity to work with other languages at the same time.

Please reconsider this comment #59 (comment): "It seems really weird to not have the fix be the default". It would be really nice to have good defaults and it also would be really nice to have the ability to tailor theme for C++ too.

[alekseyt]

Consider this image:

This is how it would look like in Dark+ in vscode:

I guess Dark+ is more consistent. Preferable approach for me here is to actually disable highlighting on MyClass in MyClass::f() {} to make it more consistent. So ultimately Dark+ approach wins just by having less sophisticated highlighting and not trying to tailor itself for C++ syntax, right?

[matter123]

entity.name.{function, type, namespace,etc} not extending to include the scope resolution is probably a bug and resolving that would help some of the inconsistencies.

The problem with simpler is that C++ is a complex language. Simple wither doesn't mark things at all or gets it wrong.

[alekseyt]

I don't say that liberty to highlight something is a bad thing. I'm just saying that it might be easier to disable some highlighting when it is needed for one reason or another. Just my 2c.

[matter123]

What is wrong with the highlighting of MyClasd? If it's the fact that it's a typo. The grammar has no way of knowing that.

We are working on highlighting MyClass::MyClass() see #80 (currently blocked by #127). So that should be improved.

[alekseyt]

There is nothing terribly wrong in tagging, i'm just trying to explain what i have to deal with when working on theme. You are absolutely right that C++ is a complex language and i'm not saying that syntaxing has to implement entire C++ compiler nor it has to be adjusted to fit particular theme.

All i'm saying is that it would be easier if namespace would be namespace everywhere and a function would be a function everywhere. If you have your own considerations - you are very welcome to have them. I hope my explanations did help at least for a bit, thank you for your hard work, i'm looking forward for future releases.