-
Notifications
You must be signed in to change notification settings - Fork 5.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Manage content on the C# 7 draft specification work #29101
Comments
Are there any examples of what was done in the past? Either way, I’m inclined to agree with your suggestions since there seems to be a lot of thought that went into it. |
Not yet. This is the first time we're updating the standard in public when the feature specs were also in public. (It's fun to write that last sentence). |
Redirects: I have a slight lean to the first occurrence. I think anyone who is reaching back to speclets may want the full feature, and at least will be more patient to multiple hops. Your description of that as the most complete set of links drives my opinion here. When: Whatever is reasonably easy for the folks working on this. I do not see this as a big issue. I agree that there should be a decision for consistency. |
Is there any chance of getting an example that would be changed? I.e., a link to a speclet and then where it would redirect to in either case? I feel like "seeing" what's going to happen might help? |
Good point. When dotnet/csharpstandard#104 is merged, this speclet can be removed from docs. This is a good example for the following reasons:
Another good example is dotnet/csharpstandard#236, which would replace this article. The most extreme example is dotnet/csharpstandard#63. It's more extreme because the feature spec for Tuples was never in the dotnet/csharplang repo, but the updates for inferred tuple element names and tuple equality are published. Note that the committee will get to many of the smaller features before tackling Tuples, which is the spec is changing the most. |
In the case of your first example, where would - https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-7.0/local-functions - redirect to after its removal? Sorry for all the questions, just not 100% clear on where it would go 🙂 |
Where: I think we should strive to redirect to the place that most fully describes the new feature. I think it's likely to be the most useful. Folks that want to dig into the full set of changes associated with the feature can do so via the PR that introduces it. When: Agree that this should be consistent, and vaguely lean towards doing them as they become ready. |
The C# standard committee will soon begin reviewing and merging feature PRs for C# 7.x features. There are a number of docs tasks that need to happen. some require discussion:
When to remove speclets requires some discussion:
The speclets won't be removed from the dotnet/csharplang. They remain useful for historical purposes, and to better understand why different decisions were made.
Where to redirect links?
When the speclet is retired, all internal and external links to the version published on docs will break. Internal links are easy: We'll catch those in the build, and re-target to the best location in the updated standard. We handle external links by configuring redirections. Where should we send those links?
For some of the features, multiple clauses in the standard will change. See the draft PRs for examples. Some of the PRs will be obvious (new literal additions is an example). Others change several areas (pattern matching is an example). Current options would be:
I'm leaning toward the "largest" change for a feature (even though that's subjective). I'd like responses in the comments.
When to retire speclets?
The second question is when to make the PRs to remove speclets now incorporated in the standard. There are two reasonable options:
I'm leaning toward as soon as the feature PR is merged. That avoids any discrepancies in the descriptions that the standards committee has resolved. One concern could be if there are links between speclets of features that have been merged, and those that haven't. I think that will be handled by the committee for ease of managing the features for each release. Again, I'd like comments.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
The text was updated successfully, but these errors were encountered: