@zwarich Yup, if you want to facilitate single-pass alias analysis for cases like that you want the opposite of C's register keyword and default semantics. If you have a pointer vs reference dichotomy, you can still allow references to locals to be formed by default as long as something prevents that kind of rebinding.
@chandlerc I’m following Carbon pretty closely, and hope that it succeeds so there are fewer and fewer contexts in which I could be asked to write C++.
However, I’m a bit puzzled by the safety story. What makes you confident that you can focus on adding safety after the fact and succeed rather than building it in from the beginning?
Better modeling of the distinction between values and storage. This has been a pain for Rust, esp. regarding semantics of unsafe code and enabling optimizations. I'm mildly skeptical this will continue unabated in Carbon, just because of the need to take pointer references to temporary values for API reasons. In a perfect world, having a memory address and having a readable (and/or writable value) would be completely separated from each other.
FWIW, the current model already explicitly materializes storage for temporaries when a pointer is needed as you say. But we have a concrete event where that occurs and we have to start thinking in terms of storage. So I think we're in a good position for readable values to be completely separated from storage.
Whether we add mutable value semantics (w/o storage) is a really interesting question, and something we're keeping open (and looking at Hylo and others to learn about).
Can someone please make a value-oriented systems language with implicits? I’d really like Comparable to be implemented for T and an accompanying Context rather than just a T.
@foonathan On 64-bit systems, there's often an advantage to using 32-bit indices instead of pointers, but this imposes a requirement that you always have a context available with which to interpret these indices. But all of the traits/interfaces/etc. for equality, comparison, hashing, etc. will not let you use the context in order to implement them.
A language with implicit arguments (and possibly singleton types or some other mechanism of linking a value with its context) would fix this.
How bad would it be if a systems language only had user-specified inlining, specified at function declarations, function parameter declarations, or the call site? I’ll even allow automatic inlining of single use local functions as a bonus.
@lgerbarg@resistor@zwarich So a normal library/program could exploit this for their memory-mapped DB, for example? Or does it need special key signing like some of the debug server stuff apparently does?
@d_christiansen I really enjoyed the Functional Programming in Lean book, and was generally impressed to see the transformation from Lean 3 to 4 in terms of usability as a programming language.
Are there any potential new features that you think would really improve the Lean programming experience?
@zwarich I don't think that there is "the Lean programming experience" - a person's experience will be determined by their background, their environment, and much more. Different features serve different people.
@zwarich that said - error messages, documentation, an auto-formatter, IntelliJ-style refactorings and test runner, Agda-style case splitting and holes, and a debugger all seem like candidates that would help a wide swath of users
@pervognsen I thought about it some more and this gets interesting when you combine it with your previously stated dislike of compound expressions. Defining separate test expressions get very similar to what you mentioned in the other sub-thread about defining local blocks with control effects.
@pervognsen@zwarich It's also interesting how "silly newbie instincts", like if (thing == true) { ... } in this case, sometimes point to something deeper.
@graydon Do the results of the .NET green threads experiment make you feel somewhat vindicated? https://github.com/dotnet/runtimelab/issues/2398
Unless I am mistaken, .NET (via F# and then C#) is the source of the contemporary async/await model.
@pervognsen Right, from what I've seen of embedded coding, I'd expect the designers to have a static hard bound on the stack size, and provision based on that, green threads or not.
@pervognsen@graydon In the original .NET context, most of those problems have easier solutions due to the existence of a GC’d runtime, at least until you hit the FFI.
We need a systems language that just gives up on undefined padding, makes padding bytes zero, and opens the door to a future of bytewise equality/hashing.
@foonathan@zwarich Ah gotcha, I didn't know that's what that meant. It seems doable to add zeroed padding with a derive macro. But yeah, I've always wanted (at least opt-in) well-defined padding in systems languages too.