Skip to content
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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Fix broken links #4560

wants to merge 1 commit into from

Conversation

Youssef1313
Copy link
Member

No description provided.

@Youssef1313 Youssef1313 requested a review from a team as a code owner March 19, 2021 13:36
@@ -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.
Copy link
Contributor

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.

Copy link
Member Author

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?

Copy link
Contributor

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".

Copy link
Member Author

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".

Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants