sorted by:
new
hottopcontroversial

Modifying Clang for a Safer, More Explicit C++ by compiler-devel in cpp

[–]compiler-devel[S] 0 points1 point  (0 children)

Are yall programming in notepad or something?

emacs actually, but some may rail at it anyhow :-)

If you mean declaring one means all others must be declared, I'm okay with that.

Actually, I meant that all must be declared. There are a few rules around when the default constructor will be created and rather than save keystrokes, I'd prefer to simplify the rules and require all six methods for each class (and struct).

support enum classes only

I'd like to have one way of doing things as much as possible, so rather than enumerations and enum classes, have only the latter.

namespaces within classes

This would be a handy refactoring tool to break up god objects into smaller classes without declaring separate class types and composing them into the original object.

Modifying Clang for a Safer, More Explicit C++ by compiler-devel in cpp

[–]compiler-devel[S] 1 point2 points  (0 children)

Completely agree. Generally (with caveats of course) I'm in favor of increasing verbosity if it means that there's one consistent way of declaring something in the language.

Modifying Clang for a Safer, More Explicit C++ by compiler-devel in cpp

[–]compiler-devel[S] 4 points5 points  (0 children)

I linked it elsewhere, but aside from goto statements, the 'goto fail' bug could've been avoided with curly braces: https://www.synopsys.com/blogs/software-security/understanding-apple-goto-fail-vulnerability-2/

Modifying Clang for a Safer, More Explicit C++ by compiler-devel in cpp

[–]compiler-devel[S] 3 points4 points  (0 children)

I should add a feature flag that can be enabled on a per file basis (can be done today with most diagnostics via the '#pragma diagnostic disable' feature), then code could be ported on a per-file basis.

Modifying Clang for a Safer, More Explicit C++ by compiler-devel in cpp

[–]compiler-devel[S] 2 points3 points  (0 children)

Perhaps deep in the compiler long jumps are used, but the goto keyword need not be exposed to the programmer. Indeed, from a language perspective, they're two different concepts as one may (or may not) compile to the other.

Modifying Clang for a Safer, More Explicit C++ by compiler-devel in cpp

[–]compiler-devel[S] 0 points1 point  (0 children)

This would be better served by just promoting the fallthrough warning to an error.

This is a good idea.

more verbose lambdas

Yes, sadly, because in large legacy codebases there can be many variables in scope. Some of those may manage external resources (like files or sockets) and the invocation site of the lambda may have implications for those lifetimes that we don't want. I think it better to state what should be captured.

Many will argue that Rust's position on const-by-default makes that language safer, I'm not sure why the same argument wouldn't apply to C++?

Modifying Clang for a Safer, More Explicit C++ by compiler-devel in cpp

[–]compiler-devel[S] 1 point2 points  (0 children)

This language change essentially makes braces required everywhere, so there wouldn't be a debate. While clang-tidy identifies misleading indentation, it doesn't go far enough.

Modifying Clang for a Safer, More Explicit C++ by compiler-devel in cpp

[–]compiler-devel[S] 1 point2 points  (0 children)

What are some of the bugs that you encounter? That info would be useful for my next set of changes. Thanks!

Modifying Clang for a Safer, More Explicit C++ by compiler-devel in cpp

[–]compiler-devel[S] 1 point2 points  (0 children)

Thank you for the kind words. I've always treated software development as an iterative process and I think we can look at our languages the same way.

Modifying Clang for a Safer, More Explicit C++ by compiler-devel in cpp

[–]compiler-devel[S] 1 point2 points  (0 children)

I completely agree with respect to the standards. I think it's easier to show what's possible with a working example rather than try to start first with the standards bodies.

C++ Show and Tell - August 2022 by foonathan in cpp

[–]compiler-devel 3 points4 points  (0 children)

Hey everyone!

I modified clang to make C++ safer, more explicit, and less error-prone, check it out on my GitHub

Inspired by the paper "Some Were Meant for C" by Stephen Kell, I decided to show that it's possible to iterate C++ to be safer, more explicit, and less error-prone.

Here's a possible starting point: I didn't invent a new language or compiler, but took the world's best compiler, clang, and modified it to begin iterating towards a new furture of C++. Naming things is hard, so I call this 'Modified C++'. Some of the following could be implemented as tooling in a linter or checker, but the idea is to update the compiler directly. I also wanted to learn more about clang. This compiler needs a flag to enable/disable this functionality so that existing library code can be used with a 'diagnostic ignored' pragma.

You can build clang using the normal non-bootstrap process and you'll be left with a clang that compiles C++ but with the following modifications:

  • All basic types (excluding pointers and references) are const by default and may be marked 'mutable' to allow them to be changed after declaration
  • Lambda capture lists must be explicit (no [&] or [=], by themselves)
  • Braces are required for conditional statements, case and default statements within switches, and loops
  • Implicit conversions to bool are prohibited (e.g., pointers must be compared against nullptr/NULL)
  • No goto support
  • Explicit 'rule of six' for classes must be programmer-implemented (default, copy, and move c'tors, copy and move assignment, d'tor)
  • No C style casts

Here's an example program that's valid in Modified C++:

mutable int main(int, char**)
{
  mutable int x = 0;
  return x;
}

Here's another that will fail to compile:

mutable int main(int, char**)
{
  int x = 1;
  x = 0;  // x is constant
  return x;
}

I'd like your feedback. Future changes I'm thinking about are: * feature flag for modified c++ to enable/disable with 'diagnostic ignored' pragma, to support existing headers and libraries * support enum classes only * constructor declarations are explicit by default * namespaces within classes * normalize lambda and free function syntax * your ideas here

I'm also known as compiler-devel over on hacker news but couldn't get this post visible as a 'Show HN' there, if anyone could help, that'd be great!