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

31–40 of 91 posts

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

#31

Post by nextaccountic »

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 business logic not corrupt memory and cause havok with UB! Dereferencing arbitrary pointers is a dangerous operation that shouldn't be done in everyday code. If I'm writing data structures I'm willing to think about UB, but if I'm choosing the color of a widget I'm less so. I'm not expecting you solve this hard problem, but at least a general direction or a half solution that works for a % of the cases would be cool (or at least state this is a long term goal).

And of course there's the comparison to Rust, but Rust is actually just a data point in this solution space and perhaps new languages can afford to try new approaches

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

#32

Post by jesse__ »

> 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-consequence programming errors that I make are, and "oops, I mutated that thing that I could have marked const" is a class of error that consumes a vanishingly small amount of my debugging time.

The errors I make that account for a large portion of my debugging time are errors related to semantics of my program. Things that, in C++, are typically only detectable at runtime, but with a better type system could be detected at compile time. The first step for this might be type annotations that specify valid values. For example, being able to annotate whether an argument is or is not allowed to be null, and having that enforced at call sites.

(NOTE: I also don't spend a meaningful amount of time debugging accidental nullptr values, but that's a good first step towards the type annotations I _do_ want)

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

#33

Post by dataflow »

nextaccountic wrote: post #23
compiler-devel wrote: post #19

Earlier quoted context omitted.

Some implicit conversions are okay, like type promotion from int to double. Some type coercions are fraught, like char to int or back again. I agree that array decay to pointer could be explicit, and pointers shouldn't cast to arrays.

implicit int to double is really, really bad! it can silently truncate - double can only store 53 bits integers so for large integers the result will not be an integer! in general, lossy conversions should never, ever be implicit

I would instead say int should be guaranteed to fit in a double. I feel like there's no reason to introduce a pitfall in > 99.999% of use cases just because there might be some obscure architecture where int is 64-bit and its programmers cannot be bothered with the extra keystroke for 'long'.

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

#34

Post by favorited »

compiler-devel wrote: post #19
bartwe wrote: post #7

Ok some more suggestions: - Pointers aren't arrays. - no implicit conversions at all. - require fields to be initialized before use/end of constructor

Some implicit conversions are okay, like type promotion from int to double. Some type coercions are fraught, like char to int or back again. I agree that array decay to pointer could be explicit, and pointers shouldn't cast to arrays.

I'd love to see integer promotion die in a fire, to prevent this: https://twitter.com/stephentyrone/status/1410636445593837569

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

#35

Post by jesse__ »

bartwe wrote: post #7

Ok some more suggestions: - Pointers aren't arrays. - no implicit conversions at all. - require fields to be initialized before use/end of constructor

> require fields to be initialized before use

Good idea. That would catch annoying bugs I rarely, but occasionally, have.

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

#36

Post by diegoperini »

kllrnohj wrote: post #21
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…

> [&] 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…

Swift calls them Escaping Closures.

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

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

#37

Post by Findecanor »

vlovich123 wrote: post #3

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

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++.

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

#38

Post by archi42 »

- define the evaluation order for function parameters, e.g. f(a(), b()) [or is that well defined in modern C++?]

- allow for named arguments. E.g. let's say for the definition f(int a = 12, int b = 42), one might call f(b: 1337) or f(12, 1337). Not allowing mixing of named & positional is probably a good idea.

- take a look at static verification and remove language features that make static verification more difficult and think about how you could replace them (or remove; but e.g. function pointers & similar stuff fall in that category and are probably to powerful to be sacrificed this way)

//Edit: as others have said, try to whack as much undefined behaviour as possible (and in case you can't, don't accept the input program).

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

#39

Post by tyfighter »

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 would prefer "var" or "varying".

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

#40

Post by ithkuil »

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.

Post reply on HN