-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Fix broken links #4560
base: main
Are you sure you want to change the base?
Fix broken links #4560
Conversation
@@ -48,8 +48,8 @@ Changes are made to the algorithm determining the meaning of a *namespace_or_typ | |||
|
|||
This is the relevant bullet point with proposed additions (which are **in bold**): | |||
* If the *namespace_or_type_name* is of the form `I` or of the form `I<A1, ..., Ak>`: | |||
* If `K` is zero and the *namespace_or_type_name* appears within a generic method declaration ([Methods](classes.md#methods)) and if that declaration includes a type parameter ([Type parameters](classes.md#type-parameters)) with name `I`, then the *namespace_or_type_name* refers to that type parameter. | |||
* Otherwise, if the *namespace_or_type_name* appears within a type declaration, then for each instance type `T` ([The instance type](classes.md#the-instance-type)), starting with the instance type of that type declaration and continuing with the instance type of each enclosing class or struct declaration (if any): | |||
* If `K` is zero and the *namespace_or_type_name* appears within a generic method declaration ([Methods](../spec/classes.md#methods)) and if that declaration includes a type parameter ([Type parameters](../spec/classes.md#type-parameters)) with name `I`, then the *namespace_or_type_name* refers to that type parameter. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure if we want to make these changes in GlobalUsingDirective.md because the links are correct in context of the section where this text is supposed to go. The purpose of the document is to show the proposed diff, and no changes to the links are proposed. Same probably applies to changes in constant_interpolated_strings.md.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@AlekseyTs Can you elaborate more on "the links are correct in context of the section where this text is supposed to go"?
Does that mean in the future when the proposal is part of the actual spec?
If so, shouldn't this be done when this happens in future?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unless the section is a new section (doesn't have a link right after the header), the non-bold text is not that interesting, it is a direct quote from the original spec and its purpose is to establish context for proposed additions (in bold). I intentionally didn't make any other changes or "fixes".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see now it's a direct copy from spec/basic-concepts.md, but I don't see why the link shouldn't be fixed? This defeats the purpose of this being a "link".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am fine with that. That link is unimportant here.
No description provided.