www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Things C++ 20 Deliberately Broke

reply Walter Bright <newshound2 digitalmars.com> writes:
https://docs.google.com/presentation/d/1HwLNSyHxy203eptO9cbTmr7CH23sBGtTrfOmJf9n0ug/edit?usp=sharing&resourcekey=0-GH5F3wdP7D4dmxvLdBaMvw

https://news.ycombinator.com/item?id=32969957
Sep 25 2022
next sibling parent reply norm <norm.rowtree gmail.com> writes:
On Sunday, 25 September 2022 at 23:01:52 UTC, Walter Bright wrote:

 https://docs.google.com/presentation/d/1HwLNSyHxy203eptO9cbTmr7CH23sBGtTrfOmJf9n0ug/edit?usp=sharing&resourcekey=0-GH5F3wdP7D4dmxvLdBaMvw

 https://news.ycombinator.com/item?id=32969957


I agree with the general sentiment on ycombinator, most of the 
"breakages" are things deprecated because it plugs a hole in the 
language. So a Chromium developer is on the migration trail and 
doesn't like it. Many of the "solutions" are things like "use 
explicit casts", which is a good thing because it exposes where 
they are side-stepping the type system to reopen the holes 
plugged by C++20.

There are two paths; Python2/3 new language or or deprecation 
like C++ and D. Either way end-users have to walk that migration 
at some point to upgrade to the new language.
Sep 25 2022
parent reply Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Monday, 26 September 2022 at 03:24:57 UTC, norm wrote:

 There are two paths; Python2/3 new language


https://www.techrepublic.com/article/programming-languages-why-python-4-0-will-probably-never-arrive-according-to-its-creator/

Python developers discovered that people dislike compatibility 
breaking
changes. So if a programming language wants to be successful, then
this has to be taken into account.


 or deprecation like C++ and D.


C++ and D are actually radically different. Older versions of the 
C++
standard are still supported via the '-std=c++98' or '-std=c++17' 
option
in GCC (or its equivalent in the other C++ compilers). And C++ is 
not
unique. For example, Rust also supports different language 
editions.
If Python developers decided to keep both Python2 and Python3
maintained forever, then it would be similar to C++ and Rust.

D doesn't offer anything like this right now.


 Either way end-users have to walk that migration at some point 
 to
 upgrade to the new language.


End-users don't have to migrate if they still have an option to 
keep
using the older version of the language standard when compiling 
their
code. This is very useful for large projects. Chromium developers
are safely staying at C++17 while evaluating C++20. Nobody is 
pulling
the rug from under their feet.
Sep 26 2022
next sibling parent ryuukk_ <ryuukk.dev gmail.com> writes:
On Monday, 26 September 2022 at 08:32:27 UTC, Siarhei Siamashka 
wrote:

 On Monday, 26 September 2022 at 03:24:57 UTC, norm wrote:

 There are two paths; Python2/3 new language


 https://www.techrepublic.com/article/programming-languages-why-python-4-0-will-probably-never-arrive-according-to-its-creator/

 Python developers discovered that people dislike compatibility



"Python developers discovered that people who WERE using Python 
dislike breaking
changes"

Also:

Python developers discovered that by making important breaking 
changes and overall making all the changes required to improve 
the language will attract many more people that didn't like 
Python previously, and gave it a new life, making it the most 
popular interpreted language on the planet


The people stuck will get replaced, nobody likes to use stuck 
things, wether we like it or not, it doesn't matter, at some 
point we will be replaced by a new generation of humans, that's 
life

Up to us to leave something for them to play with, being stuck 
doesn't help!

C++20 is trying to make changes to attract new users, whether 
it'll work or not is another story, i personally believe the 
changes are not deep enough (still require forward declaration 
for modules, wich is dumb)
Sep 26 2022
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 26 September 2022 at 08:32:27 UTC, Siarhei Siamashka 
wrote:

 [snip]
 C++ and D are actually radically different. Older versions of 
 the C++
 standard are still supported via the '-std=c++98' or 
 '-std=c++17' option
 in GCC (or its equivalent in the other C++ compilers). And C++ 
 is not
 unique. For example, Rust also supports different language 
 editions.
 If Python developers decided to keep both Python2 and Python3
 maintained forever, then it would be similar to C++ and Rust.

 D doesn't offer anything like this right now.
 [snip]


D has preview/revert switches for some individual behaviors 
(though to my knowledge, not all deprecations have this). What it 
doesn't have is a way to combine several of these together based 
on an individual year/period and automation to switch to a newer 
edition. Rust has some good tooling for that.
Sep 26 2022
parent reply Don Allen <donaldcallen gmail.com> writes:
On Monday, 26 September 2022 at 12:41:07 UTC, jmh530 wrote:

 On Monday, 26 September 2022 at 08:32:27 UTC, Siarhei Siamashka 
 wrote:

 [snip]
 C++ and D are actually radically different. Older versions of 
 the C++
 standard are still supported via the '-std=c++98' or 
 '-std=c++17' option
 in GCC (or its equivalent in the other C++ compilers). And C++ 
 is not
 unique. For example, Rust also supports different language 
 editions.
 If Python developers decided to keep both Python2 and Python3
 maintained forever, then it would be similar to C++ and Rust.

 D doesn't offer anything like this right now.
 [snip]


 D has preview/revert switches for some individual behaviors 
 (though to my knowledge, not all deprecations have this). What 
 it doesn't have is a way to combine several of these together 
 based on an individual year/period and automation to switch to 
 a newer edition. Rust has some good tooling for that.


Rust just released v1.64 of their system. 1018 people contributed 
to the new release.

D has nothing like that kind of developer horsepower. So we 
should realize that it may be simply be beyond the project's 
capacity to provide things, however useful or shiny, that we see 
in other languages.

D is obviously not my project, but to the extent this hasn't been 
thought about (I'd guess it has), I'd suggest taking stock of 
what the project ambitions are. I think of D as kind of the 
OpenBSD of the programming language world. OpenBSD is not nearly 
as successful, measured by user count, as Linux. But it's 
excellent work and serves a very useful purpose in the niche it 
has established for itself. But they do make compromises because 
of the limited developer capacity, e.g., they still don't have a 
unified buffer cache and the file-system is ancient (no COW, no 
journaling, though they do still support McKusick's soft 
dependencies).

I see D the same way. In my view, it's a lot better than C or 
C++. Is it going to replace either of them? Of course not. But 
there is a community of D users that understands its value and 
what the D project has accomplished and that appears to be enough 
for people like Walter to keep the project going, much like the 
OpenBSD situation. And a major plus for D is that Walter doesn't 
behave like Theo de Raadt :-)

In previous posts, I've described how D has served me well 
personally, allowing me to turn some really disgusting C into 
something manageable. I won't repeat any of that. But I would 
like to mention that I first tried to do this work in Rust. The 
big problem is that my main application has some global state; it 
is simply unavoidable. That application is also single-threaded, 
because of its nature. Rust has made the decision to assume that 
all applications are multi-threaded and therefore mutable globals 
are unsafe. To use them for global state, you end up with your 
code absolutely littered with "unsafe" blocks. You can try to use 
interior mutability and/or thread_local! to get around this. Good 
luck. So what you get is at least as ugly as my original C and 
with so many unsafe blocks, what about Rust's vaunted safety 
claims?

I think they should instead have provided an option to state that 
your code is single-threaded and will remain so, relaxing the 
stringency about multi-threaded-ness that just doesn't apply. 
This would allow writing inherently single-threaded code in a 
much more straight-forward way. But as the language is now, I had 
an incredibly frustrating experience and abandoned it. I could 
have made it work, but it was like going from the frying pan into 
the fire. D was an absolute delight after this experience.
Sep 26 2022
next sibling parent Dukc <ajieskola gmail.com> writes:
On Monday, 26 September 2022 at 19:51:30 UTC, Don Allen wrote:

 And a major plus for D is that Walter doesn't behave like Theo 
 de Raadt :-)


Indeed, it is one of the virtues of Walter that you don't see him 
deliberately insulting anyone. That's something that's far from 
the norm among famous open-source contributors. Theo de Raadt is 
definitely not alone with shortcomings in that.
Sep 26 2022
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 26 September 2022 at 19:51:30 UTC, Don Allen wrote:

 [snip]

 Rust just released v1.64 of their system. 1018 people 
 contributed to the new release.

 [snip...]


Fair points.
Sep 26 2022
parent M.M. <matus email.cz> writes:
On Monday, 26 September 2022 at 20:46:49 UTC, jmh530 wrote:

 On Monday, 26 September 2022 at 19:51:30 UTC, Don Allen wrote:

 [snip]

 Rust just released v1.64 of their system. 1018 people 
 contributed to the new release.

 [snip...]


 Fair points.


At the same time, Rust v1.60 was released with the help of 299 
people, v1.61 with 331 people, v1.62 with 329 people, and v1.63 
with 366 people. So until recently, the difference in manpower 
was certainly significant, but not HUGE. (For comparison, the 
versions 2.100, 2.099, 2.098, and 2.097 of D were contributed by 
41, 100, 62, and 54 contributors.)

I think D can stay a viable language in the future. It does not 
need to become the most popular language in the world.
Sep 26 2022
prev sibling parent reply German Diago <german.diago cppmaster.net> writes:
On Monday, 26 September 2022 at 08:32:27 UTC, Siarhei Siamashka 
wrote:

 On Monday, 26 September 2022 at 03:24:57 UTC, norm wrote:



 If Python developers decided to keep both Python2 and Python3
 maintained forever, then it would be similar to C++ and Rust.


Not at all. Python 2/3 is a split with incompatibilities. C++ is 
a deprecation + removal model except for very, very few 
exceptions. You can compile C++98 code in a C++20 compiler almost 
without any change.
Sep 28 2022
parent reply Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Wednesday, 28 September 2022 at 19:43:34 UTC, German Diago 
wrote:

 On Monday, 26 September 2022 at 08:32:27 UTC, Siarhei Siamashka 
 wrote:

 On Monday, 26 September 2022 at 03:24:57 UTC, norm wrote:



 If Python developers decided to keep both Python2 and Python3
 maintained forever, then it would be similar to C++ and Rust.


 Not at all. Python 2/3 is a split with incompatibilities.


These were not fatal incompatibilities though. Single-source 
Python 2/3 compatible code used to be a thing:

* https://docs.python.org/3/howto/pyporting.html
* https://python-future.org/compatible_idioms.html

Of course having two slightly incompatible variants of the 
programming language is not ideal. That's surely some extra work 
for compiler/interpreter developers and also extra work for 
popular libraries developers. But application developers didn't 
have any urgency to waste resources on migrating their existing 
Python2 code to Python3 and instead could focus on delivering 
amazing features to their users.

Is the convenience of 1 compiler developer or the convenience of 
1000 application developers more important for a programming 
language? The answer depends on many factors. And the size of the 
existing ecosystem is one of them.


 C++ is a deprecation + removal model except for very, very few 
 exceptions. You can compile C++98 code in a C++20 compiler 
 almost without any change.


You can surely compile a simplistic C++98 helloworld code by a 
C++20 compiler with no changes at all. But Chromium developers 
couldn't easily compile their C++17 code by a C++20 compiler. 
That's exactly what this forum thread is all about. The key 
difference is that Chromium is a huge project.

C++ language has multiple supported versions of the language 
standard for a reason and this is a lifesaver for the projects 
with huge codebases, which have to be maintained over the span of 
many years or decades. If C++ compilers decided to drop support 
for the older versions of the language standard, then this would 
be similar to what Python did.
Sep 28 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 29 September 2022 at 02:57:33 UTC, Siarhei Siamashka 
wrote:

 But Chromium developers couldn't easily compile their C++17 
 code by a C++20 compiler.


Wasn't most of the issues compiler warnings?
Sep 29 2022
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 9/25/22 7:01 PM, Walter Bright wrote:

 https://docs.google.com/presentation/d/1HwLNSyHxy203eptO9cbTmr7CH23sBGtTrfOmJf9n0ug/edit?usp=sharing&resourcekey=0-GH
F3wdP7D4dmxvLdBaMvw 
 
 
 https://news.ycombinator.com/item?id=32969957
 


 From the document:


 Math between disparate enums is deprecated


Why? Why can't you add one enum to another when they are based on int, 
as long as it's typed as int?

I'm honestly curious as to the problems this is solving.

-Steve
Sep 26 2022
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 26 September 2022 at 22:15:49 UTC, Steven 
Schveighoffer wrote:

 On 9/25/22 7:01 PM, Walter Bright wrote:

 https://docs.google.com/presentation/d/1HwLNSyHxy203eptO9cbTmr7CH23sBGtTrfOmJf9n0ug/edit?usp=sharing&resourcekey=0-GH5F3wdP7D4dmxvLdBaMvw
 
 
 https://news.ycombinator.com/item?id=32969957
 


 From the document:


 Math between disparate enums is deprecated


 Why? Why can't you add one enum to another when they are based 
 on int, as long as it's typed as int?

 I'm honestly curious as to the problems this is solving.


Bugs. An enum is representant an enumeration or a set. You should 
not mix those without a cast. C++ has the upgraded «enum class» 
for this. You should usually use constexpr for constants.
Sep 26 2022
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 9/26/22 6:30 PM, Ola Fosheim Grøstad wrote:

 On Monday, 26 September 2022 at 22:15:49 UTC, Steven Schveighoffer wrote:

 On 9/25/22 7:01 PM, Walter Bright wrote:

 https://docs.google.com/presentation/d/1HwLNSyHxy203eptO9cbTmr7CH23sBGtTrfOmJf9n0ug/edit?usp=sharing&resourcekey=0-GH
F3wdP7D4dmxvLdBaMvw 



 https://news.ycombinator.com/item?id=32969957


 From the document:


 Math between disparate enums is deprecated


 Why? Why can't you add one enum to another when they are based on int, 
 as long as it's typed as int?

 I'm honestly curious as to the problems this is solving.


 
 Bugs. An enum is representant an enumeration or a set. You should not 
 mix those without a cast. C++ has the upgraded «enum class» for this. 
 You should usually use constexpr for constants.
 
 


I misremembered how enums work in (old) C/C++. But it seems really 
awkward to make it difficult to extract the real value. I also don't see 
a huge harm in it implicitly converting, as D has allowed.

I suppose using namespaces and constexpr, one can *almost* mimic the 
behavior. But it's still not a type.

It seems the intuitive behavior is not readily accessible with C++.

-Steve
Sep 26 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 27 September 2022 at 01:54:19 UTC, Steven 
Schveighoffer wrote:

 I misremembered how enums work in (old) C/C++. But it seems 
 really awkward to make it difficult to extract the real value. 
 I also don't see a huge harm in it implicitly converting, as D 
 has allowed.

 I suppose using namespaces and constexpr, one can *almost* 
 mimic the behavior. But it's still not a type.


Hm, do you mean enums or constexpr? Constexpr constants are 
usually put inside a class. So you access them as 
`ClassName::constant_name`. C++20 also allows accessing enums 
through the class scope by allowing the `using` statement to 
apply to enums inside a class definition. So you can certainly 
build an enum like type with more advanced features than regular 
enums in C++. You can do it with enums, or without enums.

You can use enums to create new nominal integers. An example of 
this is std::byte which is defined like this:

```C++
enum class byte : unsigned char {} ;

```

As a result you cannot use operators on a `byte` and you now have 
a type for unassuming octets. You can do this for your own 
integer-based type quite easily and  define the operations you 
want.


 It seems the intuitive behavior is not readily accessible with 
 C++.


The intuitive behaviour for an enumeration are the operations: 
comparison, successor, predecessor.

It gets a bit messier in C/C++ as you also tend to use it for 
bitsets. Which probably should be a different concept. Anyway, 
I've started to use `enum class` for almost everything and then 
define overloaded set-functions that work on them. That way you  
encapsulate the casting and bit manipulation and hopefully get 
fewer bugs as a result.
Sep 27 2022
prev sibling parent norm <norm.rowtree gmail.com> writes:
On Monday, 26 September 2022 at 22:15:49 UTC, Steven 
Schveighoffer wrote:

 On 9/25/22 7:01 PM, Walter Bright wrote:

 https://docs.google.com/presentation/d/1HwLNSyHxy203eptO9cbTmr7CH23sBGtTrfOmJf9n0ug/edit?usp=sharing&resourcekey=0-GH5F3wdP7D4dmxvLdBaMvw
 
 
 https://news.ycombinator.com/item?id=32969957
 


 From the document:


 Math between disparate enums is deprecated


 Why? Why can't you add one enum to another when they are based 
 on int, as long as it's typed as int?

 I'm honestly curious as to the problems this is solving.

 -Steve


Two disparate enums are not the same type and they are not int. 
Like feet and meters are both represented using float.

So C++20 take on this is if you want to do math between disparate 
enums you must explicitly cast to a common type like int, which 
states clearly on the page and to the compiler you know what 
you're doing.
Sep 26 2022