Should param descriptions be duplicated for primary constructors

[gewarren]

If you generate an XML documentation file for a class with a primary constructor, the parameter doc descriptions are duplicated on the type and on the constructor. Is that necessary? For maintenance and file size, it seems like it would be better to only have the descriptions on the constructor. Example XML doc file:

        <member name="T:Person">
            <summary>
            Represents a person
            </summary>
            <param name="FirstName">The person's first name.</param>
            <param name="LastName">The person's last name.</param>
        </member>
        <member name="M:Person.#ctor(System.String,System.String)">
            <summary>
            Represents a person
            </summary>
            <param name="FirstName">The person's first name.</param>
            <param name="LastName">The person's last name.</param>
        </member>

And the type itself:

/// <summary>
/// Represents a person
/// </summary>
/// <param name="FirstName">The person's first name.</param>
/// <param name="LastName">The person's last name.</param>
public class Person(string FirstName, string LastName);

[RikkiGibson]

I agree that only the constructor should have these, as the primary constructor has these parameters, not the type. I would assume records should behave the same way. However, I'm curious to know what others think. @dotnet/roslyn-compiler.

[CyrusNajmabadi]

i'm surprised this is how things work. my intuition was that param docs would only be on the constructor.

[AlekseyTs]

For simplicity, we don't try to split content of the doc comment on parts that belong exclusively to the type and exclusively to the constructor. I am not even sure if it is possible to do so for every possible situation. For example, a parameter reference tag can probably appear anywhere. The summary can talk about type and the constructor, but perhaps in different paragraphs. We have chosen, perhaps, not the perfect world solution, but the simple and sufficiently good one. It is probably not ideal for generation of a stand-alone documentation, but sufficiently good for a dev to document the code itself. If the behavior is causing a problem for a user, there is a way out, to use a regular constructor instead. I am not sure whether it is worth to put any additional effort into trying to make the behavior perfect.