Initial commit

Author: WojciechMazur

README.md

@@ -0,0 +1,5 @@
+# Scala Native Improvement Proposals
+
+This repository contains the Scala Native Improvement Proposal - a list of Scala Native future improvements, similar to the [Scala Improvement Proposals](https://github.com/scala/improvement-proposals) dedicated to the core Scala-lang.
+
+Currently, Scala Native Improvement Process is not well defined, like [SIPs](https://docs.scala-lang.org/sips), however, they can be approved or discarded by the Scala Native core team. SNIPs, similarly to [RFC](https://en.wikipedia.org/wiki/Request_for_Comments) can be treated as a form of public discussion to share, comment and review new possible Scala Native improvements, before starting actual work on the given ideas.

proposals/.keep

@@ -0,0 +1,88 @@
+---
+layout: sip
+stage: implementation
+status: waiting-for-implementation
+title: SNIP-NN - Title of the Proposal
+---
+
+**By: Author A and Author B and Author C**
+
+## History
+
+| Date          | Version            |
+|---------------|--------------------|
+| Feb 19th 2022 | Initial Draft      |
+| Feb 20th 2022 | Alteration Details |
+
+## Summary
+
+A summary of the proposed changes. This should be no longer than 3 paragraphs. It is intended to serve in two ways:
+
+- For a first-time reader, a high-level overview of what they should expect to see in the proposal.
+- For returning readers, a quick reminder of what the proposal is about.
+
+## Motivation
+
+A high-level overview of the proposal with:
+
+- An explanation of the problems or limitations that it aims to solve,
+- A presentation of one or more use cases as running examples, with code showing how they would be addressed *using the status quo* (without the feature), and why that is not good enough.
+
+This section should clearly express the scope of the proposal. It should make it clear what are the goals of the proposal, and what is out of the scope of the proposal.
+
+## Proposed solution
+
+This is the meat of your proposal.
+
+### High-level overview
+
+A high-level overview of the proposed changes, and how they allow to better solve the running examples. This section should be example-heavy, and not dive into corner cases.
+
+Example:
+
+~~~ scala
+// This is an @main method
+@main def foo(x: Int): Unit =
+  println(x)
+~~~
+
+### Specification
+
+A specification for the proposed changes, as precise as possible. This section should address difficult interactions with other language features, possible error conditions, and corner cases as much as the good behavior.
+
+For example, if the syntax of the language is changed, this section should list the differences in the grammar of the language. If it affects the type system, the section should explain how the feature interacts with it.
+
+### Compatibility
+
+A justification of why the proposal will preserve backward binary and NIR compatibility. Changes are backward binary compatible if the bytecode produced by a newer compiler can link against library bytecode produced by an older compiler. Changes are backward NIR compatible if the NIR files produced by older compilers can be read, with equivalent semantics, by the newer tooling.
+
+If it doesn't do so "by construction", this section should present the ideas of how this could be fixed (through deserialization-time patches and/or alternative binary encodings). It is OK to say here that you don't know how binary and TASTy compatibility will be affected at the time of submitting the proposal. However, by the time it is accepted, those issues will need to be resolved.
+
+This section should also argue to what extent backward source compatibility is preserved. In particular, it should show that it doesn't alter the semantics of existing valid programs.
+
+### Other concerns
+
+If you think of anything else that is worth discussing about the proposal, this is where it should go. Examples include interoperability concerns, cross-platform concerns, implementation challenges.
+
+### Open questions
+
+If some design aspects are not settled yet, this section can present the open questions, with possible alternatives. By the time the proposal is accepted, all the open questions will have to be resolved.
+
+## Alternatives
+
+This section should present alternative proposals that were considered. It should evaluate the pros and cons of each alternative, and contrast them to the main proposal above.
+
+Having alternatives is not a strict requirement for a proposal, but having at least one with carefully exposed pros and cons gives much more weight to the proposal as a whole.
+
+## Related work
+
+This section should list prior work related to the proposal, notably:
+
+- A link to the Pre-SNIP discussion that led to this proposal,
+- Any other previous proposal (accepted or rejected) covering something similar as the current proposal,
+- Whether the proposal is similar to something already existing in other languages,
+- If there is already a proof-of-concept implementation, a link to it will be welcome here.
+
+## FAQ
+
+This section will probably initially be empty. As discussions on the proposal progress, it is likely that some questions will come repeatedly. They should be listed here, with appropriate answers.