Would you please mind not inserting new values to Microsoft.Dynamics.Nav.CodeAnalysis.SyntaxKind?!

[MODUSCarstenScholling]

1. Describe the bug For every major release in the last 3 years, even some minors of the AL Language code analysis, the position of several Enum values was changed by inserting new values somewhere in the middle. Especially SyntaxKind is affected.

While it does not make any difference for your own tool stack (all dlls are compiled in one build), some of us are using self-developed analyzers running wild when registering or checking a SyntaxKind, because the compiled values do not correspond to the runtime values anymore.

This causes a mass of false positives or other issues after updating or switching to another version of the AL Language extension.

I understand that the BC analyzer framework is not public, but SyntaxKind and other Enums are. Would you please mind not inserting but adding new values to Microsoft.Dynamics.Nav.CodeAnalysis.SyntaxKind? Or set every entry to a unique value (like SymbolKind)?

2. To Reproduce I hope the issue is clear with the explanation above.

3. Expected behavior SyntaxKind and other Enum values must not change its values and meaning between releases.

4. Actual behavior SyntaxKind and other Enum values change their values and meaning between releases.

5. Versions: Any version of BC, AL Language and VSCode since a long time.

@esbenk, @pborring Would that be something (easy to do) you would take into consideration for the next release?

[EmilDamsbo]

Hello, thank you for taking the time to report this. Unfortunately, due to the layout of that enum, where we try to keep related syntax kinds in groupings, this is unlikely to change. If we were to only append and not insert in the middle, getting an overview of the syntax kinds related to certain constructs would be near impossible.

[MODUSCarstenScholling]

Thank you for your response, Emil.

Hmm, what about grouping by assigning values to the first entry of each group?

Like this:

    public enum SyntaxKind : ushort
    {
        None = 0,
        EmptyToken,

        Int32LiteralToken = 1000,
        Int64LiteralToken,
        DecimalLiteralToken,
        // [...]
        BadToken,

        FalseKeyword = 2000,
        TrueKeyword,
        // [...]
        GreaterThanEqualsToken,

        CommaToken = 3000,
        DotToken,
        // [...]
        CloseBraceToken,

        // [...]
    }

If you add new values to the end of a group, you keep groups, keep the order, keep (external) relations, and easily put a smile on our faces with only a ridiculously small one-time administrative overhead. What do you think?

[EmilDamsbo]

That is a fair suggestion. I'll mark this for triage to discuss internally. Thank you for contributing

[qutreson]

Thank you for the suggestion. This was discussed with the team, however the code analysis dlls are currently not public and we cannot promise to avoid such breaking changes. Closing then this issue. We would recommend logging a BC Ideas on aka.ms/BCIdeas for making these dlls public.