Highlight record functions as functions in semantic colourisation

[saul]

Fixes#2718

Note the bold functions in records below:

Also enum cases are now highlighted as enum cases:

See also #2410

[saul]

cc @cloudRoutine

[KevinRansom]

nice

[vasily-kirichenko]

I'm not sure about this change. What about class / record / DU properties? Are you gonna color them as functions if they have function type? What about type aliases like type Foo = unit -> int?

[vasily-kirichenko]

And what about everything that has Func<> or Action<> type?

[cloudRoutine]

How about we use the convention that the semantic coloring should match the reflective metadata of the construct?

[cloudRoutine]

@vasily-kirichenkoFunc<_> and Action need to be invoked so they wouldn't be at issue

[KevinRansom]

@vasily-kirichenko this PR addresses members of records, making enum members look like enums seems reasonable, and function members look like functionss seems reasonable.

@cloudRoutine the reflective metadata is (kind of) an implementation detail ... so may not be the best heuristic. We should probably discuss the semantic elements on a case by case basis and come to a conclusion for each on its merits. For example, today I had to discus keyword types names being cyan not blue, because someone prefers blue to cyan ... I.e they are keywords not types, which seems like a particularly bizarre argument to me.

Perhaps we should consider how to make this configurable, then people can select options to match their preferences.

Kevin

[dsyme]

I'm not sure about this change. What about class / record / DU properties? Are you gonna color them as functions if they have function type?

I kind of agree with this perspective - there is nothing particularly special about record properties.

Whatever we do should be consistent across properties associated with other types. It's easy to keep adding special cases like this and then find that the overall experience is inconsistent, or highlights differences between constructs that F# actually wants you to consider as related.

It goes back to a point I made a couple of days ago: in user code, F# generally emphasizes similarity (e.g. between classes and records, or between an active pattern and regular pattern, or a method and a property, or an F# call and a .NET call, or a method and a function value etc.. etc. etc.) rather than difference. The tooling should generally try to do this too - or take care when highlighting differences.

Anyway, think through it, I'm just mentioning the need for care w.r.t. consistency.