Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Modifying Clang for a Safer, More Explicit C++

github.com

Post reply on HN
Print view View original

41–50 of 91 posts

Re: Show HN: Modifying Clang for a Safer, More Explicit C++

#41

Post by cweagans »

compiler-devel wrote: post #6
chakkepolja wrote: post #4

Apart from the mutable keyword, can't these be implemented as a clang diagnostic plugin? Then it can be used to enforce a stricter style guide. As another commenter pointed, mutable will be probably of limited use anyway.

Yes, some (maybe most) could be implemented in a plugin. I wanted to make these changes in part to better understand the clang internals and also show that rather than use external tooling, the language itself can (should?) be changed.

I would submit that C++ has enough inertia (as a language and as an ecosystem) that changing the language itself would be difficult.

However, C++ is a huge language and if there's a way to enforce safety by using only a subset of the language + tooling to help you do that, your improvements could be adopted piecemeal by teams looking to level up their codebase a bit.

Many languages have a way to opt in to e.g. strict type checking on a per-file basis. It would be really cool to see these improvements implemented in such a way that existing codebases could gradually adopt them.

Re: Show HN: Modifying Clang for a Safer, More Explicit C++

#42

Post by tyfighter »

ithkuil wrote: post #40
tyfighter wrote: post #39

I really do not understand the Rust-esque love of the "mutable" keyword in rebellion of "const". They are most often attached to variables. The definition of the word variable is "subject to variation or changes". By definition, variables change. Constants do not change. I understand that the semantics here are historical, but it's very much like "Automated ATM Machine". Maybe I just don't like the word mutable, and…

"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 is subject change doesn't make much more sense.

It is fine for "things" to be immutable by default, and in fact I think they should be. I just think "mutable" is keyword smell similar to "decltype" because type wasn't keyworded from the start.

Re: Show HN: Modifying Clang for a Safer, More Explicit C++

#44

Post by nwallin »

I think this is an interesting idea but I also think it will never gain adoption.

Move constructors/Move assignment should be noexcept by default. It's not entirely clear to me what a program ought to do if a move constructor/assignment operator throws an exception. In a general sense you cannot 'trust' the old object to not have been modified.

"All basic types (excluding pointers and references) are const by default" -- why the exception?

The rule of zero should be acceptable in addition to the rule of 6. Also, the rule of 5 is acceptable in many circumstances; lots of classes should not have default constructors. I agree that having 1,2,3, or 4 are bad, but 0,5,6 are acceptable.

Re: Show HN: Modifying Clang for a Safer, More Explicit C++

#45

Post by _kst_ »

One suggestion: In documentation and comments, distinguish clearly between "const" and "constant".

"const" means "read-only", and probably should have been spelled "readonly".

"constant", as in "constant expression", means evaluated at compile time.

For example: `const int r = rand();` is perfectly valid: r can't be computed until run time (it's not constant), but it can't be modified after its initialization (it is const/readonly).

Re: Show HN: Modifying Clang for a Safer, More Explicit C++

#46

Post by _kst_ »

enedil wrote: post #14
compiler-devel wrote: post #5

Earlier quoted context omitted.

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 declarati…

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.

Re: Show HN: Modifying Clang for a Safer, More Explicit C++

#47

Post by gautamcgoel »

wjko21 wrote: post #24

what's the motivation for removing `goto`, is this something that you find being abused? I code in c++ for work, and I almost never see anyone using it without a good reason.

Yeah, I'm curious about this as well. I know the Go and Lua creators explicitly included goto in their languages, saying it can be useful if used carefully.

Re: Show HN: Modifying Clang for a Safer, More Explicit C++

#48

Post by leni536 »

nwallin wrote: post #44

I think this is an interesting idea but I also think it will never gain adoption. Move constructors/Move assignment should be noexcept by default. It's not entirely clear to me what a program ought to do if a move constructor/assignment operator throws an exception. In a general sense you cannot 'trust' the old object to not have been modified. "All basic types (excluding pointers and references) are const by default…

Many standard containers don't have noexcept move operations in Microsoft's implementation. It is conforming. Having a throwing move doesn't mean that you can't have exception guarantees. Just do the throwing operations before you modify the source or target objects.

Re: Show HN: Modifying Clang for a Safer, More Explicit C++

#49

Post by nlewycky »

nlewycky wrote: post #26

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.
Post reply on HN