Comment by vlovich123 | Hacker News Reader

Comment by vlovich123 | Hacker News Reader

> - All basic types (excluding pointers and references) are const by default and may be marked 'mutable' to allow them to be changed after declaration

If you're not changing how const works, then this has limited utility in C++ because C++ const has all sorts of problems (e.g. not transitive). Also, what does the "mutable" annotation for a free function (i.e. main) mean? That just seems weird.

> - Lambda capture lists must be explicit (no [&] or [=], by themselves)

[&] is pretty valuable in cases where you do something like invokeSynchronously([&] {...})

I don't know that your changes will ever see much adoption because it won't be able to compile anything more complex than a "hello world" program as all the things you disallow are used & the porting effort is not cosmetic. Additionally, you're not actually fixing any of the problems people have with C++. So:

1. Consider fixing const semantics if you're going down the path of defining a new language

2. Think about how to fix memory safety and issues around UB which are the #1 sharp edges for C++

I don't know if you're achieving the goal of a safer, less error-prone language with the changes outlined. Have you looked at the things Carbon [1] is doing? I'd say that's an attempt to define a spiritual successor to C++, one that can easily interoperate with C++ but when you stay within the language it's safer.

[1] https://github.com/carbon-language/carbon-lang

Thank you for this great feedback. I'll do my best to respond to each of your points:

WRT const, you're correct and I'd need to go further in updating const behaviors in the language. I stole this idea from Rust (sort of) in that variable declarations in that language are const by default. Essentially, I wanted to 'flip' the semantics in C++ to match, and use mutable to allow variables to change after their declaration. I could go further to enforce transitivity (e.g. so you can't do something like mutable x = y; where y is const).

[&] is handy indeed yet this was motivated by my experience in legacy heavy codebases where there are often many variables in scope and some with external consequences (e.g. file descriptors, sockets). I don't want these accidentally captured if the lambda invocation site has lifetime implications beyond those resources.

I think I'm achieving the goal of a safer, less error-prone language because these changes could've prevented the 2014 'goto fail' from happening (and not just because the keyword goto would be omitted but because there was a conditional without braces in the affected source making the code less explicit and less clear).

https://www.synopsys.com/blogs/software-security/understandi...

mutable x = y in my opinion should be allowed. After all the new variable is just a copy of old one. Why shouldn't you be able to modify it?

Agreed, just like mutable x = 42 should be allowed.

Yes, good point, I retract what I said before. Thanks!

> [&] is handy indeed yet this was motivated by my experience in legacy heavy codebases where there are often many variables in scope and some with external consequences (e.g. file descriptors, sockets). I don't want these accidentally captured if the lambda invocation site has lifetime implications beyond those resources.

I think your solution to that problem goes the wrong way, though. The problem is whether or not a lambda can survive past the immediate usage, not what it captures. Listing those resources explicitly still gives you the same bug, banning [&] didn't avoid it.

I'd suggest instead an approach where a template taking a callable annotates whether or not it's "inline". If it is inline, then [&] should just be the default even. If it's not, then ban [&]. Possibly ban taking anything by reference if it's not a synchronously-used lambda even.

(inline / non-inline terms here cribbed from Kotlin https://kotlinlang.org/docs/inline-functions.html - probably there's a better word for it, but whatever)

Swift calls them Escaping Closures.

https://docs.swift.org/swift-book/LanguageGuide/Closures.htm...

Just don't fall into the trap of believing that only making constness transitive would make it fool-proof.

A non-"pure" const member function with const parameters could still call some other function with access to a "mutable" alias to what you have a const reference to. You would need something more, such as an ownership system to make the compiler make that impossible (as in Rust) or to detect it (the topic of Master's thesis, BTW ) ... but then it would no longer be something resembling C++.

Generally speaking a const member function can't call a member function that is non-const or a member function that modifies a member variable that's not declared mutable. If the present const member function has a const reference to something that's marked mutable, then it's effectively a no-op as far as const value qualifications are concerned.

Reply on news.ycombinator.com