6 ms·

Can C++ be 10x Simpler and Safer?

40 points by krona 4y ago

effnorwood 4y ago
andrewmcwatters 4y ago
I don't like C++ Syntax 2. I like the idea of bringing safety to C++, but I believe that Syntax 2 is an excuse create a new language and reuse the C++ name. It reminds me of what Google did with AngularJS and Angular. It is dishonest on its face and turns me off toward listening further. C++ has this issue of every few years looking entirely different. There's no long-lasting thought about how changes or additions to the language will echo into perpetuity. I do not know the totality of what issues we face when working with C++ (or C) outside of say, bounds safety, optimization issues that cause undefined behavior, and implicit conversion problems, but I do have a feeling that every time I see safety issues in C++ (or C) they can almost always be addressed by using an already existing safe alternative, asking whether or not a supposed "valid" optimization should be considered valid if in combination with another optimization it causes undefined behavior, or creating library functions which assist with converting what would otherwise be implicit type conversions to explicit with error checking.
- Quekid5 4y ago
  > but I do have a feeling that every time I see safety issues in C++ (or C) they can almost always be addressed by using an already existing safe alternative, I mean, the almost-simplest abstraction possible the std::vector has potential UB right in its [] operator. Sure, you could theoretically always do "at(...)", but good luck convincing anybody else on to use this safer, yet more verbose and "slower" alternative to []. There are lots of these things in the STL. (For trickier things, see iterator invalidation, etc.) A lot of the unsafety is also baked into basic language primitives, e.g. dangling references/pointers because of confusion around lifetime, etc., etc. There's just sooooo much that you have to get 100% right as a programmer and adding abstractions (while a definite improvement in many cases, e.g. smart pointers) hasn't proven to be nearly enough.
  - torrent 4y ago
    > I mean, the almost-simplest abstraction possible the std::vector has potential UB right in its [] operator. It's your responsibility to pass the allowed range of value to a function. It a function description tells you to e.g. pass only non-null pointers or only even integers then it's your fault if you don't do it. Inside the function there may me asserts but there is no need to such checks in general. > There's just sooooo much that you have to get 100% right as a programmer It's simply the job of the programmer to get it 100% right. No language can do this job for you.
    - Quekid5 4y ago
      I'm not sure what to say. You're replying in the context of a post about why people literally do not and cannot get it right 100% of the time. Thinking so is pure hubris. (And demonstrably so.) EDIT: The fundamental problem with the "attitude" of C++ I see is that fast-and-potentially-UB by default is a bad default (as almost all defaults in C++ are). It would be far saner to have slow-but-guaranteed-behavior by default[0]... but the C++ committee has repeatedly demonstrated that they're not willing to do that. Well, it's either that or require the compiler to prove that the fast behavior is safe (an example of which is Rust), but that's likely not feasible in C++... unless you turn it into Rust with even more obscure and verbose annotation. [0] At least you can stay safe and then optimize as needed from there.
      - torrent 4y ago
        > why people literally do not and cannot get it right 100% of the time. Thinking so is pure hubris. Sure we all don't get it right 100% on the first write. For this reason we test and iterate. Equally you could say that it is pure hubris that a language will enable you to make your code right 100% of the time. You mean the vector::operator[] is an example of fast-and-potentially-UB ? I don't see any UB if the constraints are met (keeping the index within valid range). If they are not willing in a specific case they for sure had specific reasons not to be.
        4y ago
- simplotek 4y ago
  > (...) but I believe that Syntax 2 is an excuse create a new language and reuse the C++ name. This. It looks like a blatant attempt to ride the coattails of C++, which oddly enough is not the first case coming from Redmond (see C++/CX). If the concept is able to fly on its own without these marketing crutches then it would be more credible to just claim it's a successor.
  - gpderetta 4y ago
    I'm willing to cut Herb Sutter some slack and assume he has good intentions and the future of the language at heart.
- torrent 4y ago
  Syntax is mostly a matter of taste. Preference of taste and style changes with time and trends. Why should "let name : type" be preferred to "type name"? Just because others do it? Why and this unnecessary, additional ':'? > C++ has this issue of every few years looking entirely different So what. The style you have been using does the job then just keep it. There is no obligation switch to use new stuff. You should stick with that what proved to be successful.
  - Kranar 4y ago
    The reason some languages use "let name: type" instead of "type name" is to eliminate various ambiguities, for example C++'s most vexing parse, or the classic C typedef ambiguity where a statement like "X * Y" is ambiguous because it could be the declaration of a variable Y whose type is "X*" where "X" is a typedef, or it could be the multiplication of a variable "X" with a variable "Y". There are many languages where the "type" can be a fairly complex composition that can introduce ambiguities. Modern languages use a type of syntax where all declarations start with an introducer, something along the lines of "let", "fn", "class", etc... in order to eliminate ambiguities as well as avoid the need for the parser to have potentially unbounded look-ahead.
    - steveklabnik 4y ago
      Additionally, for let specifically, it’s much nicer of a diff to explicitly annotate types vs having them inferred. int x = 5; auto x = 5; vs let x: i32 = 5; let x = 5; (This is one part the practical impact of a lot of your comment is about, of course, just also adding this little bit to make it concrete.)
fercircularbuf 4y ago
Herb Sutter is such an inspiration. His talk here demonstrating his cpp2 language and cpp2 to cpp compiler cppfront is required viewing for both C++ enthusiasts and those looking to jump to other languages.
krona 4y ago
Compiler Explorer just added support for Cpp2: https://godbolt.org/ https://godbolt.org/
xeonmc 4y ago
I propose a new flavour of C++ focused on safety using only a subsest of its footguns. Name it "C-Safe-Safe" and abbreviated as "CSS".
xt00 4y ago
This seems great -- I hope this concept of improving C++ takes off -- telling people to just switch to Rust is pretty lame.. tons of huge code-bases exist that are C++.
torrent 4y ago
I think it would be more constructive to propose a constrained subset, get rid of legacy, propose default behaviours for parts that are undefined and so on. Stuff that does not belong to this subset can still be used within an unconstrained clause. If I read e.g. "Why build Carbon?" on https://github.com/carbon-language/carbon-lang https://github.com/carbon-language/carbon-lang I dont find any concrete reasons or proves that show why C++ should be abandoned for something completely new but somehow very similar. There are so many question around the actual language definition like who maintains it, how is the standardization process. Who will adapt to it or to something else. ... This seems all so utopic. I have been using C++ for many years with fantastic success. It allows me to create all I want/need from embedded to high performance projects. That you may shot you in the foot is in fact not bad. It compels you to be careful and think deeply about the design and only use what you completely understand. With other languages your program might not crash but probably will do wrong things like eat up memory or access still references outdated data. You will find error much later in the process when it costs multiple magnitudes more.
- esperent 4y ago
  > I think it would be more constructive to propose a constrained subset, get rid of legacy, propose default behaviours for parts that are undefined and so on We could call it c+++
  - pauljurczak 4y ago
    I proposed C+++ name many years ago, and I don't think I was the first one to do so...
karmakaze 4y ago
There are so many shallow comments for this deeply thought out, 7 year effort to date. If the rest of the 'to do' items gets tackled, implemented in prototypes, and made into proposals as some of the work to date has been handled, this has the best chance of being a true C++ successor. The goal is nothing more than fulfilling these B. Stroustrup quotes: "Inside C++, there is a much smaller and cleaner language struggling to get out." (1994) "Say 10% of size of C++ in definition and front-end compiler size. ... Most of the simplification would come from generalization." (2007) There's a summarization at 1:14:39[0] where concepts are listed on the left, and C++ syntax for handling these concepts in different contexts are on the right. The point of this effort is reduce the accidental complexity syntax on the right by refactoring it into concise uniform syntax. This effort is broad and much more than sugar, e.g. eliminating forward declarations. The talk up to that time is giving examples of the work that has been done in many of those areas, with remaining to-do's listed. Basically the language that is being extracted is the actual language that current C++ programmers really think in, but don't have a more concise way of writing than C++. [0] https://youtu.be/ELeZAKCN4tY?t=6099 https://youtu.be/ELeZAKCN4tY?t=6099
karmakaze 4y ago
One highlighted point struck a chord with me. All the different forms of closures and function bodies are cut from a single complete form with some parts omitted. Like how a URL can have many optional parts that we don't normally use but fit in without invalidating other things you know about how to write them. The exact opposite was all the function/lambda syntax forms in Swift.

40 points by krona 4y ago

I don't like C++ Syntax 2. I like the idea of bringing safety to C++, but I believe that Syntax 2 is an excuse create a new language and reuse the C++ name. It reminds me of what Google did with AngularJS and Angular. It is dishonest on its face and turns me off toward listening further. C++ has this issue of every few years looking entirely different. There's no long-lasting thought about how changes or additions to the language will echo into perpetuity. I do not know the totality of what issues we face when working with C++ (or C) outside of say, bounds safety, optimization issues that cause undefined behavior, and implicit conversion problems, but I do have a feeling that every time I see safety issues in C++ (or C) they can almost always be addressed by using an already existing safe alternative, asking whether or not a supposed "valid" optimization should be considered valid if in combination with another optimization it causes undefined behavior, or creating library functions which assist with converting what would otherwise be implicit type conversions to explicit with error checking.

Quekid5 4y ago
> but I do have a feeling that every time I see safety issues in C++ (or C) they can almost always be addressed by using an already existing safe alternative, I mean, the almost-simplest abstraction possible the std::vector has potential UB right in its [] operator. Sure, you could theoretically always do "at(...)", but good luck convincing anybody else on to use this safer, yet more verbose and "slower" alternative to []. There are lots of these things in the STL. (For trickier things, see iterator invalidation, etc.) A lot of the unsafety is also baked into basic language primitives, e.g. dangling references/pointers because of confusion around lifetime, etc., etc. There's just sooooo much that you have to get 100% right as a programmer and adding abstractions (while a definite improvement in many cases, e.g. smart pointers) hasn't proven to be nearly enough.
- torrent 4y ago
  > I mean, the almost-simplest abstraction possible the std::vector has potential UB right in its [] operator. It's your responsibility to pass the allowed range of value to a function. It a function description tells you to e.g. pass only non-null pointers or only even integers then it's your fault if you don't do it. Inside the function there may me asserts but there is no need to such checks in general. > There's just sooooo much that you have to get 100% right as a programmer It's simply the job of the programmer to get it 100% right. No language can do this job for you.
  - Quekid5 4y ago
    I'm not sure what to say. You're replying in the context of a post about why people literally do not and cannot get it right 100% of the time. Thinking so is pure hubris. (And demonstrably so.) EDIT: The fundamental problem with the "attitude" of C++ I see is that fast-and-potentially-UB by default is a bad default (as almost all defaults in C++ are). It would be far saner to have slow-but-guaranteed-behavior by default[0]... but the C++ committee has repeatedly demonstrated that they're not willing to do that. Well, it's either that or require the compiler to prove that the fast behavior is safe (an example of which is Rust), but that's likely not feasible in C++... unless you turn it into Rust with even more obscure and verbose annotation. [0] At least you can stay safe and then optimize as needed from there.
    - torrent 4y ago
      > why people literally do not and cannot get it right 100% of the time. Thinking so is pure hubris. Sure we all don't get it right 100% on the first write. For this reason we test and iterate. Equally you could say that it is pure hubris that a language will enable you to make your code right 100% of the time. You mean the vector::operator[] is an example of fast-and-potentially-UB ? I don't see any UB if the constraints are met (keeping the index within valid range). If they are not willing in a specific case they for sure had specific reasons not to be.
      - 4y ago
simplotek 4y ago
> (...) but I believe that Syntax 2 is an excuse create a new language and reuse the C++ name. This. It looks like a blatant attempt to ride the coattails of C++, which oddly enough is not the first case coming from Redmond (see C++/CX). If the concept is able to fly on its own without these marketing crutches then it would be more credible to just claim it's a successor.
- gpderetta 4y ago
  I'm willing to cut Herb Sutter some slack and assume he has good intentions and the future of the language at heart.
torrent 4y ago
Syntax is mostly a matter of taste. Preference of taste and style changes with time and trends. Why should "let name : type" be preferred to "type name"? Just because others do it? Why and this unnecessary, additional ':'? > C++ has this issue of every few years looking entirely different So what. The style you have been using does the job then just keep it. There is no obligation switch to use new stuff. You should stick with that what proved to be successful.
- Kranar 4y ago
  The reason some languages use "let name: type" instead of "type name" is to eliminate various ambiguities, for example C++'s most vexing parse, or the classic C typedef ambiguity where a statement like "X * Y" is ambiguous because it could be the declaration of a variable Y whose type is "X*" where "X" is a typedef, or it could be the multiplication of a variable "X" with a variable "Y". There are many languages where the "type" can be a fairly complex composition that can introduce ambiguities. Modern languages use a type of syntax where all declarations start with an introducer, something along the lines of "let", "fn", "class", etc... in order to eliminate ambiguities as well as avoid the need for the parser to have potentially unbounded look-ahead.
  - steveklabnik 4y ago
    Additionally, for let specifically, it’s much nicer of a diff to explicitly annotate types vs having them inferred. int x = 5; auto x = 5; vs let x: i32 = 5; let x = 5; (This is one part the practical impact of a lot of your comment is about, of course, just also adding this little bit to make it concrete.)

fercircularbuf 4y ago

Herb Sutter is such an inspiration. His talk here demonstrating his cpp2 language and cpp2 to cpp compiler cppfront is required viewing for both C++ enthusiasts and those looking to jump to other languages.

krona 4y ago

Compiler Explorer just added support for Cpp2: https://godbolt.org/ https://godbolt.org/

xeonmc 4y ago

I propose a new flavour of C++ focused on safety using only a subsest of its footguns. Name it "C-Safe-Safe" and abbreviated as "CSS".

xt00 4y ago

This seems great -- I hope this concept of improving C++ takes off -- telling people to just switch to Rust is pretty lame.. tons of huge code-bases exist that are C++.

torrent 4y ago

I think it would be more constructive to propose a constrained subset, get rid of legacy, propose default behaviours for parts that are undefined and so on. Stuff that does not belong to this subset can still be used within an unconstrained clause. If I read e.g. "Why build Carbon?" on https://github.com/carbon-language/carbon-lang https://github.com/carbon-language/carbon-lang I dont find any concrete reasons or proves that show why C++ should be abandoned for something completely new but somehow very similar. There are so many question around the actual language definition like who maintains it, how is the standardization process. Who will adapt to it or to something else. ... This seems all so utopic. I have been using C++ for many years with fantastic success. It allows me to create all I want/need from embedded to high performance projects. That you may shot you in the foot is in fact not bad. It compels you to be careful and think deeply about the design and only use what you completely understand. With other languages your program might not crash but probably will do wrong things like eat up memory or access still references outdated data. You will find error much later in the process when it costs multiple magnitudes more.

esperent 4y ago
> I think it would be more constructive to propose a constrained subset, get rid of legacy, propose default behaviours for parts that are undefined and so on We could call it c+++
- pauljurczak 4y ago
  I proposed C+++ name many years ago, and I don't think I was the first one to do so...

karmakaze 4y ago

There are so many shallow comments for this deeply thought out, 7 year effort to date. If the rest of the 'to do' items gets tackled, implemented in prototypes, and made into proposals as some of the work to date has been handled, this has the best chance of being a true C++ successor. The goal is nothing more than fulfilling these B. Stroustrup quotes: "Inside C++, there is a much smaller and cleaner language struggling to get out." (1994) "Say 10% of size of C++ in definition and front-end compiler size. ... Most of the simplification would come from generalization." (2007) There's a summarization at 1:14:39[0] where concepts are listed on the left, and C++ syntax for handling these concepts in different contexts are on the right. The point of this effort is reduce the accidental complexity syntax on the right by refactoring it into concise uniform syntax. This effort is broad and much more than sugar, e.g. eliminating forward declarations. The talk up to that time is giving examples of the work that has been done in many of those areas, with remaining to-do's listed. Basically the language that is being extracted is the actual language that current C++ programmers really think in, but don't have a more concise way of writing than C++. [0] https://youtu.be/ELeZAKCN4tY?t=6099 https://youtu.be/ELeZAKCN4tY?t=6099

karmakaze 4y ago

One highlighted point struck a chord with me. All the different forms of closures and function bodies are cut from a single complete form with some parts omitted. Like how a URL can have many optional parts that we don't normally use but fit in without invalidating other things you know about how to write them. The exact opposite was all the function/lambda syntax forms in Swift.