[HN Gopher] Why Safety Profiles Failed
       ___________________________________________________________________
        
       Why Safety Profiles Failed
        
       Author : pjmlp
       Score  : 34 points
       Date   : 2024-10-24 21:26 UTC (1 hours ago)
        
 (HTM) web link (www.circle-lang.org)
 (TXT) w3m dump (www.circle-lang.org)
        
       | alilleybrinker wrote:
       | The article makes the particularly good point that you generally
       | can't effectively add new inferences without constraining
       | optionality in code somehow. Put another way, you can't draw new
       | conclusions without new available assumptions.
       | 
       | In Sean's "Safe C++" proposal, he extends C++ to enable new code
       | to embed new assumptions, then subsets that extension to permit
       | drawing new conclusions for safety by eliminating code that would
       | violate the path to those safety conclusions.
        
       | steveklabnik wrote:
       | Really glad to see this thorough examination of the weaknesses of
       | profiles. Safe C++ is a really important project, and I hope the
       | committee ends up making the right call here.
        
         | wyager wrote:
         | > Safe C++ is a really important project
         | 
         | What makes you say this? It seems to me like we already have a
         | lower-overhead approach to reach the same goal (a low-level
         | language with substantially improved semantic specificity,
         | memory safety, etc.); namely, we have Rust, which has already
         | improved substantially over the safety properties of C++, and
         | offers a better-designed platform for further safety research.
        
           | steveklabnik wrote:
           | I am pro any movement towards memory safety. Sure, I won't
           | stop writing Rust and start moving towards C++ for this. But
           | not everyone is interested in introducing a second toolchain,
           | for example. Also, as this paper mentions, Safe C++ can
           | improve C++ <-> Rust interop, because Safe C++ can express
           | some semantics Rust can understand. Right now, interop works
           | but isn't very nice.
           | 
           | Basically, I want a variety of approaches, not a Rust
           | monoculture.
        
           | tptacek wrote:
           | This is a thread about a C++ language feature; it's probably
           | most productive for us to stipulate for this thread that C++
           | will continue to exist. Practical lessons C++ can learn
           | moving forward from Rust are a good reason to talk about
           | Rust; "C++ should not be improved for safety because code can
           | be rewritten in Rust" is less useful.
        
       | o11c wrote:
       | "No mutable aliases" is a mistake; it prevents many useful
       | programs.
       | 
       | Now that virtual address space is cheap, it's _possible_ to
       | recompile C (or presumably C++) with a fully-safe runtime
       | (requiring annotation only around nasty things like `union
       | sigval`), but this is an ABI break and has nontrivial overhead
       | (note that AddressSanitizers has ~2x overhead and only catches
       | some optimistic cases) unless you mandate additional annotation.
        
       ___________________________________________________________________
       (page generated 2024-10-24 23:00 UTC)