3 ms·
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 be
by compiler-devel 4y ago
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).
- compiler-devel 4y agohttps://www.synopsys.com/blogs/software-security/understanding-apple-goto-fail-vulnerability-2/ https://www.synopsys.com/blogs/software-security/understandi...
- enedil 4y agomutable 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?
- _kst_ 4y agoAgreed, just like mutable x = 42 should be allowed.
- compiler-devel 4y agoYes, good point, I retract what I said before. Thanks!
- P5fRxh5kUvp2th 4y ago
- kllrnohj 4y ago> [&] 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 https://kotlinlang.org/docs/inline-functions.html - probably there's a better word for it, but whatever)
- diegoperini 4y agoSwift calls them Escaping Closures. https://docs.swift.org/swift-book/LanguageGuide/Closures.html https://docs.swift.org/swift-book/LanguageGuide/Closures.htm...