Remove template comments for easier reading experience of the markdown

proposed/swift-interop.md

@@ -1,116 +1,27 @@
 # Swift Interop
 
-<!--
-Provide the primary contacts here. Linking to the GitHub profiles is useful
-because it allows tagging folks on GitHub and discover alternative modes of
-communication, such as email or Twitter, if the person chooses to disclose that
-information.
-
-The bolded roles makes it easier for people to understand who the driver of the
-proposal is (PM) and who can be asked for technical questions (Dev). At
-Microsoft, these roles happen to match to job titles too, but that's irrelevant.
--->
-
 **Owner** [Andy Gocke](https://github.com/agocke) | [Jeremy Koritzinsky](https://github.com/jkoritzinsky)
 
-<!--
-Provide a broad problem statement here. This might include some history and the
-description of the current state of the product. The goal is to give the reader
-the ability to judge how (and how well) your feature will address the problem.
-It might also give rise to tweaks or even alternative solutions that could move
-your proposal in a different direction -- and that's a good thing. After all, if
-the direction needs to change it's best identified when your proposal is still
-being reviewed as opposed to after much of it has already been implemented. So
-it's in your best interest to ensure the reader has enough context to properly
-critique your idea.
-
-Your problem statement should be followed by the solution you're proposing to
-solve it. Don't describe specific user scenarios here but provide enough
-information so that the reader can get an overview of what you have in mind.
-It's very much desirable to make the readers curious and come up with questions.
-That puts them in the right state of mind to read the following sections
-actively.
-
-Ensure your first paragraph is a short summary of the problem and the proposed
-solution so that readers can gain a quick understanding and decide whether your
-proposal is relevant to them and thus worth spending time on. It's usually best
-to write the first paragraph last because that means you already know the punch
-line and can do a better job stating it succinctly.
--->
 The [Swift](https://developer.apple.com/swift/) programming language is developed primarily by Apple for use in their product lines. It is a successor to the previous official language for these platforms, Objective-C. C# has had limited Objective-C interop support for quite a while and it powers frameworks like MAUI and Xamarin Forms that run on Apple devices.
 
 Swift is now becoming the dominant language on Apple devices and eclipsing Objective-C. Many important libraries are now Swift-first or Swift-only. Objective-C binding is also becoming more difficult for these libraries. To continue to interoperate with external libraries and frameworks, C# needs to be able to interoperate directly with Swift, without going through an intermediate language.
 
 ## Scenarios and User Experience
 
-<!--
-Provide examples of how a user would use your feature. Pick typical scenarios
-first and more advanced scenarios later.
-
-Ensure to include the "happy path" which covers what you expect will satisfy the
-vast majority of your customer's needs. Then, go into more details and allow
-covering more advanced scenarios. Well designed features will have a progressive
-curve, meaning the effort is proportional to how advanced the scenario is. By
-listing easy things first and more advanced scenarios later, you allow your
-readers to follow this curve. That makes it easier to judge whether your feature
-has the right balance.
-
-Make sure your scenarios are written in such a way that they cover sensible end-
-to-end scenarios for the customer. Often, your feature will only cover one
-aspect of an end-to-end scenario, but your description should lead up to your
-feature and (if it's not the end result) mention what the next steps are. This
-allows readers to understand the larger picture and how your feature fits in.
-
-If you design APIs or command line tools, ensure to include some sample code on
-how your feature will be invoked. If you design UI, ensure to include some
-mock-ups. Do not strive for completeness here -- the goal of this section isn't
-to provide a specification but to give readers an impression of your feature and
-the look & feel of it. Less is more.
--->
-
 We would expect that users would be able to write C# code that can do simple Swift interop. Additionally, we would expect that for cases where the interop system does not support seamless interop, developers could write a shim in Swift that could be called from C# code. Developers should not need to write a shim in C or Assembly to interact with Swift APIs.
 
 ## Requirements
 
 ### Goals
 
-<!--
-Provide a bullet point list of aspects that your feature has to satisfy. This
-includes functional and non-functional requirements. The goal is to define what
-your feature has to deliver to be considered correct.
-
-You should avoid splitting this into various product stages (like MVP, crawl,
-walk, run) because that usually indicates that your proposal tries to cover too
-much detail. Keep it high-level, but try to paint a picture of what done looks
-like. The design section can establish an execution order.
--->
-
 In short, we should completely eliminate the required C/assembly sandwich that's currently required to call Swift from C# code, and potentially vice versa. In particular, neither C# nor Swift users should have to deal with lower-level system state, like registers or stack state, to call Swift from C#.
 
 ### Non-Goals
 
-<!--
-Provide a bullet point list of aspects that your feature does not need to do.
-The goal of this section is to cover problems that people might think you're
-trying to solve but deliberately would like to scope out. You'll likely add
-bullets to this section based on early feedback and reviews where requirements
-are brought that you need to scope out.
--->
 C# and Swift are different languages with different language semantics. It is not a goal to map every construct from one language to the other. However, there are some terms in both languages that are sufficiently similar that they can be mapped to an identical semantic term in the other language. Interop should be seen as a Venn diagram where each language forms its own circle, and interop is in the (much smaller) space of equivalent terms that are shared between them.
 
 ## Stakeholders and Reviewers
 
-<!--
-We noticed that even in the cases where we have specs, we sometimes surprise key
-stakeholders because we didn't pro-actively involve them in the initial reviews
-and early design process.
-
-Please take a moment and add a bullet point list of teams and individuals you
-think should be involved in the design process and ensure they are involved
-(which might mean being tagged on GitHub issues, invited to meetings, or sent
-early drafts).
--->
-
 - [@dotnet/interop-contrib](https://github.com/orgs/dotnet/teams/interop-contrib)
 - [@dotnet/macios](https://github.com/orgs/dotnet/teams/macios)
 - [@lambdageek](https://github.com/lambdageek)
@@ -123,23 +34,6 @@ early drafts).
 
 ## Design
 
-<!--
-This section will likely have various subheadings. The structure is completely
-up to you and your engineering team. It doesn't need to be complete; the goal is
-to provide enough information so that the engineering team can build the
-feature.
-
-If you're building an API, you should include the API surface, for example
-assembly names, type names, method signatures etc. If you're building command
-line tools, you likely want to list all commands and options. If you're building
-UI, you likely want to show the screens and intended flow.
-
-In many cases embedding the information here might not be viable because the
-document format isn't text (for instance, because it's an Excel document or in a
-PowerPoint deck). Add links here. Ideally, those documents live next to this
-document.
--->
-
 ### Runtime
 
 #### Calling Conventions
@@ -230,15 +124,7 @@ The projection tooling will not ship as part of the runtime. It should be availa
 
 ## Q & A
 
-<!--
-Features evolve and decisions are being made along the road. Add the question
-as a subheading and provide the explanation for the decision below. This way,
-you can easily link to specific questions.
-
-When you find yourself having to explain something in a GitHub discussion or in
-email, consider to update your proposal and link to your answer instead. This
-way, you avoid having to explain the same thing over and over again.
--->
+TBD
 
 ## Related GitHub Issues