From 36b110a76ca287874ecac0c0431f817fa8611829 Mon Sep 17 00:00:00 2001 From: Alex Buck Date: Fri, 2 Sep 2022 14:08:08 -0400 Subject: [PATCH] [BULK UPDATES] DocuTune - Fix build validation issues: docs-link-absolute (#6424) * [BULK UPDATE] DocuTune - Fix build validation issues: docs-link-absolute * Update format.md * Update format.md * Update format.md * Apply suggestions from code review Co-authored-by: Bill Wagner Co-authored-by: Fred Silberberg Co-authored-by: Bill Wagner --- README.md | 4 ++-- meetings/2021/LDM-2021-09-15.md | 3 +-- proposals/format.md | 22 ++++++++++------------ 3 files changed, 13 insertions(+), 16 deletions(-) diff --git a/README.md b/README.md index b7f61d64..b90ac9aa 100644 --- a/README.md +++ b/README.md @@ -30,7 +30,7 @@ Discussions that are short and stay on topic are much more likely to be read. If - Stick to the topic of the discussion. If a comment is tangential, or goes into detail on a subtopic, start a new discussion and link back. - Is your comment useful for others to read, or can it be adequately expressed with an emoji reaction to an existing comment? -Language proposals which prevent specific syntax from occurring can be achieved with [a Roslyn analyzer](https://docs.microsoft.com/en-us/visualstudio/extensibility/getting-started-with-roslyn-analyzers). Proposals that only make existing syntax optionally illegal will be rejected by the language design committee to prevent increased language complexity. +Language proposals which prevent specific syntax from occurring can be achieved with a [Roslyn analyzer](https://docs.microsoft.com/visualstudio/extensibility/getting-started-with-roslyn-analyzers). Proposals that only make existing syntax optionally illegal will be rejected by the language design committee to prevent increased language complexity. ## Proposals Once you have a fully fleshed out proposal describing a new language feature in syntactic and semantic detail, please [open an issue for it](https://github.com/dotnet/csharplang/issues/new/choose), and it will be labeled as a [Proposal](https://github.com/dotnet/csharplang/issues?q=is%3Aopen+is%3Aissue+label%3AProposal). The comment thread on the issue can be used to hash out or briefly discuss details of the proposal, as well as pros and cons of adopting it into C#. If an issue does not meet the bar of being a full proposal, we may move it to a discussion, so that it can be "baked" further. Specific open issues or more expansive discussion with a proposal will often warrant opening a side discussion rather than cluttering the comment section on the issue. @@ -58,7 +58,7 @@ We have a few different milestones for issues on the repo: * [Backlog](https://github.com/dotnet/csharplang/milestone/10) is the set of championed proposals that have been triaged, but are not being actively worked on. While discussion and ideas from the community are welcomed on these proposals, the cost of the design work and implementation review on these features are too high for us to consider community implementation until we are ready for it. * [Any Time](https://github.com/dotnet/csharplang/milestone/14) is the set of championed proposals that have been triaged, but are not being actively worked on and are open to community implementation. Issues in this can be in one of 2 states: needs approved specification, and needs implementation. Those that need a specification still need to be presented during LDM for approval of the spec, but we are willing to take the time to do so at our earliest convenience. * [Likely Never](https://github.com/dotnet/csharplang/milestone/13) is the set of proposals that the LDM has rejected from the language. Without strong need or community feedback, these proposals will not be considered in the future. -* Numbered milestones are the set of features that have been implemented for that particular language version. For closed milestones, these are the set of things that shipped with that release. For open milestones, features can be potentially pulled later if we discover compatability or other issues as we near release. +* Numbered milestones are the set of features that have been implemented for that particular language version. For closed milestones, these are the set of things that shipped with that release. For open milestones, features can be potentially pulled later if we discover compatibility or other issues as we near release. ## Language Design Meetings diff --git a/meetings/2021/LDM-2021-09-15.md b/meetings/2021/LDM-2021-09-15.md index 5ff499fe..ebd5ff1a 100644 --- a/meetings/2021/LDM-2021-09-15.md +++ b/meetings/2021/LDM-2021-09-15.md @@ -21,7 +21,7 @@ have an initial conversion of an internal Microsoft C# specification of C# 3, wh team has converted the C# 5 specification to markdown, and is currently working to integrate the changes from our C# 6 spec into that version. -These dual versions of the specification can confuse users. The language reference on docs.microsoft.com comes from the csharplang +These dual versions of the specification can confuse users. The language reference on Microsoft Docs comes from the csharplang version of the spec, but the TC-49 version of this specification has had a number of bug fixes and is a better markdown conversion overall. Because of this the csharplang version of the spec gets occasional pull requests to update various things, from English spelling and grammar issues to actual spec bugs, but many times those issues have already been fixed in the TC-49 version of the specification. To @@ -70,4 +70,3 @@ time with more examples of the types of code it would enable. No conclusions today. We want to see the specification PR updated with more motivating samples, including samples from real code, before we make any conclusions on these issues. - diff --git a/proposals/format.md b/proposals/format.md index c90bd812..2ca7f159 100644 --- a/proposals/format.md +++ b/proposals/format.md @@ -53,7 +53,7 @@ One such potential implementation is the following. Consider all `params` invoca could allocate an array which has a size equal to the largest `params` invocation and use that for all of the invocations by creating appropriately sized `Span` instances over the array. For example: -``` csharp +```csharp static class OneAllocation { static void Use(params Span spans) { ... @@ -69,7 +69,7 @@ static class OneAllocation { The compiler could choose to emit the body of `Go` as follows: -``` csharp +```csharp static void Go() { var args = new string[3]; args[0] = "jaredpar"; @@ -93,7 +93,7 @@ This optimization cannot always be applied though. Even though the callee cannot still be captured in the caller when there is a `ref` or a `out / ref` parameter that is itself a `ref struct` type. -``` csharp +```csharp static class SneakyCapture { static ref int M(params Span span) => ref span[0]; @@ -165,7 +165,7 @@ be implemented by translating the interpolated string into the call `ValueFormat for `FormattableString.Create` today. The language will support all `params` options described in this document when looking for the most suitable `ValueFormattableString.Create` method. -``` csharp +```csharp readonly struct ValueFormattableString { public static ValueFormattableString Create(Variant v) { ... } public static ValueFormattableString Create(string s) { ... } @@ -185,7 +185,7 @@ class Program { ConsoleEx.Write(ValueFormattableString.Create((Variant)42)); ConsoleEx.Write(ValueFormattableString.Create( "hello {0}", - new Variant(DateTime.UtcNow)); + new Variant(DateTime.UtcNow))); } } ``` @@ -225,7 +225,7 @@ The CoreFX team also has a non-allocating set of storage types for up to three ` them: `CreateSpan` and `KeepAlive`. This means for a `params Span` of up to three arguments the call site can be entirely allocation free. -``` csharp +```csharp static class ZeroAllocation { static void Use(params Span spans) { ... @@ -239,7 +239,7 @@ static class ZeroAllocation { The `Go` method can be lowered to the following: -``` csharp +```csharp static class ZeroAllocation { static void Go() { Variant2 _v; @@ -269,7 +269,7 @@ This limitation is not some fundamental restriction though but instead more an a to add new op codes / intrinsics which provide universal stack allocation. These could then be used to allocate the backing storage for most `params Span` calls. -``` csharp +```csharp static class BetterAllocation { static void Use(params Span spans) { ... @@ -283,7 +283,7 @@ static class BetterAllocation { The `Go` method can be lowered to the following: -``` csharp +```csharp static class ZeroAllocation { static void Go() { Span span = RuntimeIntrinsic.StackAlloc(length: 2); @@ -319,8 +319,7 @@ How we choose will likely require a deeper investigation and examination of real are available then it will give us this type of flexibility. ### Why not varargs? -The existing -[varargs](https://docs.microsoft.com/en-us/cpp/windows/variable-argument-lists-dot-dot-dot-cpp-cli?view=vs-2017) +The existing [varargs](https://docs.microsoft.com/cpp/windows/variable-argument-lists-dot-dot-dot-cpp-cli) feature was considered here as a possible solution. This feature though is meant primarily for C++/CLI scenarios and has known holes for other scenarios. Additionally there is significant cost in porting this to Unix. Hence it wasn't seen as a viable solution. @@ -331,4 +330,3 @@ This spec is related to the following issues: - https://github.com/dotnet/csharplang/issues/1757 - https://github.com/dotnet/csharplang/issues/179 - https://github.com/dotnet/corefxlab/pull/2595 -