From 0f4ee017c53f77bccad43059aa870264a5984a70 Mon Sep 17 00:00:00 2001 From: Sean Baxter Date: Mon, 14 Oct 2024 18:24:20 -0400 Subject: [PATCH] Added abstract --- docs/P3444R0.html | 28 ++++++++++++++++++++-------- docs/draft-lifetimes.html | 28 ++++++++++++++++++++-------- lifetimes/P3444R0.md | 8 ++++++++ lifetimes/draft-lifetimes.md | 8 ++++++++ 4 files changed, 56 insertions(+), 16 deletions(-) diff --git a/docs/P3444R0.html b/docs/P3444R0.html index ad31822..51eed6b 100644 --- a/docs/P3444R0.html +++ b/docs/P3444R0.html @@ -449,7 +449,19 @@

Memory Safety without
-

1 Safe references

+

1 Abstract

+

This proposal describes the implementation of a memory-safe reference +type that does not use lifetime annotations. The goal of the proposal is +to:

+
    +
  1. Explore the viability of memory safety without lifetime +parameters.
    2. +
  2. Explain the infeasibility of making legacy lvalue and rvalue +references memory safe.
    3. +
  3. Address common objections to safety models that use lifetime +annotations.
    4. +
+

2 Safe references

“Safe C++”[safecpp] introduced a comprehensive design for compile-time memory safety in C++. The borrow checking model in Safe C++ requires lifetime parameters, a feature that increases @@ -535,7 +547,7 @@

1ref-qualifier, the implicit object parameter outlives the invented lifetime. In turn, this invented lifetime outlives the returned safe reference.

-

1.1 Exclusivity

+

2.1 Exclusivity

  • T% is a mutable safe reference. It cannot alias other references to @@ -706,7 +718,7 @@

    1.1unsafe-block is that the legacy references do not alias and do not dangle: %*x.

    -

    1.2 Constraint rules

    +

    2.2 Constraint rules

    This proposal implements two sets of constraint rules. Free functions constrain return references by the shortest of the argument lifetimes. Non-static member functions constrain return references by the implicit @@ -891,7 +903,7 @@

    free function constraint rules. The program fails borrow checking when the returned reference value2 is used after the expiration of its key temporary.

    -

    2 Second-class references

    +

    3 Second-class references

    References can be taxonimized into two classes:[second-class]

    • First-class references can pass data into functions, be returned @@ -989,7 +1001,7 @@

      3 Other aspects of safety

      +

      4 Other aspects of safety

      As detailed in the Safe C++[safecpp] proposal, there are four categories of memory safety:

        @@ -1023,7 +1035,7 @@

        [android], the benefits of rewriting are often not worth the costs. What we have to prioritize is the transition to safe coding practices[safe-coding] for new code.

        -

        4 Achieving first-class +

        5 Achieving first-class references

        The presented design is as far as I could go to address the goal of “memory safety without lifetime parameters.” But safe references aren’t @@ -1217,7 +1229,7 @@

        string_view lifetimes, causing a borrow checker failure further from the source and leaving the developer without the possibility of a fix.

        -

        5 Lifetime parameters

        +

        6 Lifetime parameters

        If there’s a community-wide research effort among compiler experts to evolve safe references it may be possible to get them into a state to support the abstractions most important for C++. But soundness reasoning @@ -1310,7 +1322,7 @@

        [rust-interop]

        -

        6 References

        +

        7 References

        [android] Eliminating Memory Safety Vulnerabilites at the Source.
        https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html?m=1
         diff --git a/docs/draft-lifetimes.html b/docs/draft-lifetimes.html index 621fce4..73cf503 100644 --- a/docs/draft-lifetimes.html +++ b/docs/draft-lifetimes.html @@ -449,7 +449,19 @@

        Memory Safety without
        -

        1 Safe references

        +

        1 Abstract

        +

        This proposal describes the implementation of a memory-safe reference +type that does not use lifetime annotations. The goal of the proposal is +to:

        +
          +
        1. Explore the viability of memory safety without lifetime +parameters.
          2. +
        2. Explain the infeasibility of making legacy lvalue and rvalue +references memory safe.
          3. +
        3. Address common objections to safety models that use lifetime +annotations.
          4. +
        +

        2 Safe references

        “Safe C++”[safecpp] introduced a comprehensive design for compile-time memory safety in C++. The borrow checking model in Safe C++ requires lifetime parameters, a feature that increases @@ -535,7 +547,7 @@

        1ref-qualifier, the implicit object parameter outlives the invented lifetime. In turn, this invented lifetime outlives the returned safe reference.

        -

        1.1 Exclusivity

        +

        2.1 Exclusivity

        • T% is a mutable safe reference. It cannot alias other references to @@ -706,7 +718,7 @@

          1.1unsafe-block is that the legacy references do not alias and do not dangle: %*x.

          -

          1.2 Constraint rules

          +

          2.2 Constraint rules

          This proposal implements two sets of constraint rules. Free functions constrain return references by the shortest of the argument lifetimes. Non-static member functions constrain return references by the implicit @@ -891,7 +903,7 @@

          free function constraint rules. The program fails borrow checking when the returned reference value2 is used after the expiration of its key temporary.

          -

          2 Second-class references

          +

          3 Second-class references

          References can be taxonimized into two classes:[second-class]

          • First-class references can pass data into functions, be returned @@ -989,7 +1001,7 @@

            3 Other aspects of safety

            +

            4 Other aspects of safety

            As detailed in the Safe C++[safecpp] proposal, there are four categories of memory safety:

              @@ -1023,7 +1035,7 @@

              [android], the benefits of rewriting are often not worth the costs. What we have to prioritize is the transition to safe coding practices[safe-coding] for new code.

              -

              4 Achieving first-class +

              5 Achieving first-class references

              The presented design is as far as I could go to address the goal of “memory safety without lifetime parameters.” But safe references aren’t @@ -1217,7 +1229,7 @@

              string_view lifetimes, causing a borrow checker failure further from the source and leaving the developer without the possibility of a fix.

              -

              5 Lifetime parameters

              +

              6 Lifetime parameters

              If there’s a community-wide research effort among compiler experts to evolve safe references it may be possible to get them into a state to support the abstractions most important for C++. But soundness reasoning @@ -1310,7 +1322,7 @@

              [rust-interop]

              -

              6 References

              +

              7 References

              [android] Eliminating Memory Safety Vulnerabilites at the Source.
              https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html?m=1
               diff --git a/lifetimes/P3444R0.md b/lifetimes/P3444R0.md index fad29ea..242eec9 100644 --- a/lifetimes/P3444R0.md +++ b/lifetimes/P3444R0.md @@ -9,6 +9,14 @@ author: toc: false --- +# Abstract + +This proposal describes the implementation of a memory-safe reference type that does not use lifetime annotations. The goal of the proposal is to: + +1. Explore the viability of memory safety without lifetime parameters. +2. Explain the infeasibility of making legacy lvalue and rvalue references memory safe. +3. Address common objections to safety models that use lifetime annotations. + # Safe references "Safe C++"[@safecpp] introduced a comprehensive design for compile-time memory safety in C++. The borrow checking model in Safe C++ requires lifetime parameters, a feature that increases expressiveness but complicates the language's type system. This proposal describes an alternative style of borrow checking, guaranteeing lifetime safety without the involvement of lifetime annotations. diff --git a/lifetimes/draft-lifetimes.md b/lifetimes/draft-lifetimes.md index d9256d5..da9c0ed 100644 --- a/lifetimes/draft-lifetimes.md +++ b/lifetimes/draft-lifetimes.md @@ -9,6 +9,14 @@ author: toc: false --- +# Abstract + +This proposal describes the implementation of a memory-safe reference type that does not use lifetime annotations. The goal of the proposal is to: + +1. Explore the viability of memory safety without lifetime parameters. +2. Explain the infeasibility of making legacy lvalue and rvalue references memory safe. +3. Address common objections to safety models that use lifetime annotations. + # Safe references "Safe C++"[@safecpp] introduced a comprehensive design for compile-time memory safety in C++. The borrow checking model in Safe C++ requires lifetime parameters, a feature that increases expressiveness but complicates the language's type system. This proposal describes an alternative style of borrow checking, guaranteeing lifetime safety without the involvement of lifetime annotations.