Don't expose enum constructor arguments to documentations

[ebraminio]

Enum constructor arguments is mostly internal detail of enums that
isn't supposed to be exposed to clients of some library so let's
don't put it in the generated documentations result.

As #2468 (comment)

Fixes #2468

Hopefully is in a correct direction, it passes the test suit I can say and even though a test is removed there is another test that practices the new behavior.

[IgnatBeresnev]

Yeah, great job! :)

[strangesource]

It was quite useful for us to have this displayed. The underlaying value in our case is an error code that can show up in logs.
Is there a way to get the old behaviour back?

[IgnatBeresnev]

@strangesource hi! You could certainly do it with a custom Dokka plugin, but is there a specific reason you don't want to document this behaviour as public API? i.e write KDoc comments on top of each enum entry?

If your docs are public, could you share the link? We'd like to learn more about your use case. At the moment we feel like enum and entry constructors are private by default and it's not supposed to be public API, but more of an internal detail.

[strangesource]

Hi @IgnatBeresnev, maybe what we are doing is not the intended use case. We certainly can add the value as a kdoc comment as well but that feels very repetitive, manual and therefore error prone.
Here is the link to our documentation. As mentioned these codes (the int numbers) show up in log statements that are e.g. send to the backend and hence are important information.

[IgnatBeresnev]

@strangesource after some internal discussions, we still feel like enum and enum entry constructors are an internal implementation detail and should not be exposed in API docs. If returned error codes are part of public API, we'd recommend documenting it either directly above enum entry or maybe create a markdown table for enum's documentation.

We understand that in your case having entry constructors makes sense and does not look out of place, but if you look at olther non-trivial cases where each entry has multiple complex constructor arguments, it does feel like it's too much

[strangesource]

Thanks considering this @IgnatBeresnev. The decision makes sense for me, we will find a way around this.