51–60 of 91 posts
Couldn't most of these be covered by a linter? I'm not sure you really need a new language for this. Even right now in Visual Studio resharper is constantly telling me about things that can be constexpr or const and a lot of the other things you mention here.
IMO it would help adoption if you supply a clang-powered rewriter into and out of your language variant. It allays the fear of losing your codebase if the compiler project dies. Reverse the default for typename. Currently some_class ::thing is assumed to be an expression where 'thing' is a variable, when we don't know which template pattern to use because there may be an explicit specialization on the T that the user…
break and continue with an integer argument, how many times to break. "break" breaks out of nearest loop, "break 2" breaks out of two. "continue 2" breaks out of one loop and then performs "continue" on the loop outside that.
outer:
for (...)
for (...)
if (...)
break outer;Earlier quoted context omitted.
Agreed, that's why I started by modifying clang. I think we can start dropping some of the crufty legacy in the C++ language without throwing it all out and starting again. While clang tidy could be used to check for a lot of these, I wanted to show that we could change the language directly and what that could look like.
> I think we can start dropping some of the crufty legacy in the C++ language (...) Do you have any concrete example of what you perceive as being "crufty legacy"?
Earlier quoted context omitted.
"const" historically means "compile-time constant". A "mutable" variable is contrasted to an "immutable" variable, not to a "constant". You may not like the name "variable" for something that cannot be changed within a given scope, but it's still something that can take multiple values during the execution of a program.
I think you missed the point I was trying to make. C/C++ currently: 1.) "variable" -> something that is subject to change 2.) "const variable" -> an unchanging thing that is subject to change (I guess you could say it only changes once). This thing and Rust: "constant" -> something unable to change "mutable constant" -> a changeable constant...what? Even "mutable variable" -> a changeable thing that is a thing that i…
"What?" indeed. Rust doesn't have "mutable constant". Rust's "const" is actually a constant, unlike in C where "const" means "Sort of immutable, although maybe not".
I guess maybe you've been told something about Rust like "let is kinda like C++ const" and so you've come to the erroneous conclusion that somehow "let mut" means "mutable constant" but that's just because you didn't really understand, blame either your attention or the poor explanation, it's surely nothing to do with Rust which has never said this is "mutable constant" since that's nonsense.
> All basic types (excluding pointers and references) are const by default and may be marked 'mutable' to allow them to be changed after declaration FWIW, for me, this is an anti-feature, and I would not use this language because of it. The net effect of this would be that I type "mutable" all over the place and get very little for my effort. I've spent a significant amount of time understanding what the high-consequ…
You might want to consider adopting a more modern programming style for the benefit of your coworkers (and possibly yourself). Mutability all over the place is a nightmare, speaking as someone who currently has to work in a large codebase written like that. It's hard to predict what value a variable is going to have at any particular point in your code, since instead of only having to check where the variable is defined, you have to audit all the code between the definition and the use. For the same reason, it's hard to guarantee that your invariants are maintained, since there is a much larger surface area to check.
Earlier quoted context omitted.
I think you missed the point I was trying to make. C/C++ currently: 1.) "variable" -> something that is subject to change 2.) "const variable" -> an unchanging thing that is subject to change (I guess you could say it only changes once). This thing and Rust: "constant" -> something unable to change "mutable constant" -> a changeable constant...what? Even "mutable variable" -> a changeable thing that is a thing that i…
> This thing and Rust: "constant" -> something unable to change "mutable constant" -> a changeable constant...what? "What?" indeed. Rust doesn't have "mutable constant". Rust's "const" is actually a constant, unlike in C where "const" means "Sort of immutable, although maybe not". I guess maybe you've been told something about Rust like "let is kinda like C++ const" and so you've come to the erroneous conclusion that…
> All basic types (excluding pointers and references) are const by default and may be marked 'mutable' to allow them to be changed after declaration FWIW, for me, this is an anti-feature, and I would not use this language because of it. The net effect of this would be that I type "mutable" all over the place and get very little for my effort. I've spent a significant amount of time understanding what the high-consequ…
This is a really great idea, specially if you can write a transpiler from general C++ into modified C++ (it can error out on corner cases and ask for manual intervention, but trivial stuff like adding missing braces can and should be done by an automatic tool, like rustfix is used to migrate between Rust editions https://github.com/rust-lang/rustfix ) But here you didn't tackle the main thing: a plan to make simple b…
All non-void return values should be [[nodiscard]] by default. Of course then you will need something else ([[discardable]]?) to indicate the ones that may safely be ignored.