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

Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

herbsutter.com

Post reply on HN
Print view View original

41–50 of 141 posts

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#41

Post by logicchains »

galkk wrote: post #37
vinkelhake wrote: post #29

Earlier quoted context omitted.

What a weird comment. What would be the point of "admitting" something that is an obvious fact? std::format, being a function for string formatting, is already part of the C++ standard library and can do some of its error checking at compile time. The paper you link is about making that error checking even better.

And that is the problem, from my pov. Instead of accepting reality that this part of c++ plain sucks and needs significant improvements, they try to do tactical updates. There are 2 names of such activities, select one which you prefer: gold plating/turd polishing...

>c++ plain sucks and needs significant improvements

What a silly thing to say. How many other mainstream languages support writing a library for compile-time checking of format strings? Having the power to do this as a library means that you can also write similar stuff customised to your own needs when you need to, as it doesn't rely on anything hard-coded in the compiler.

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#42

Post by tialaramex »

nick__m wrote: post #7
2h wrote: post #3

Earlier quoted context omitted.

Same for "safety"

reflection seems almost dead but there are 2 papers listed on Herb's summary that directly relate to safety: P2530 hazaerd pointers https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p25... P2757 type checking for std::format https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p27...

P2530 isn't really about safety, it's an example of how inadequate package management tooling results in the C++ standard library having to (very poorly) attempt the role of curator instead. C++ needs reclamation mechanisms and astoundingly even in 2023 that still means they need to live in the standard library and be designed by WG21. It's a story about institutional failure.

This is one of a pair of proposals (the other is for RCU) - both of which will likely get accepted - with useful but simplified reclamation schemes. In Rust their equivalents live on crates.io, e.g. https://crates.io/crates/haphazard is more or less the same Hazard Pointers, even based on the same work at Folly - and so they can be updated, or obsoleted, or alternatives may become prominent, it all Just Works™.

Closer to safety work is the proposal to have C++ admit that it's possible for a program to be wrong and yet not throw its hands in the air and refuse to explain what it does, as "Erroneous Behaviour". The idea is that e.g. suppose I declare there's going to be a variable named foo, which is an integer, but then I never actually initialize it. Well that's not OK, that program is nonsense, but C++ has long allowed it, even though it's nonsense, so just refusing to compile would annoy programmers. On the other hand, if foo is now silently zero, we actually introduced new semantics to the language, which isn't OK. With "Erroneous Behaviour" C++ could emit a warning ("Don't do that, uninitialized variable foo") but also zero it anyway. A new syntax would be added to mean "I genuinely don't want this initialized, for some good reason" because it's still C++ so being needlessly dangerous is part of their whole ethos, but at least you did it on purpose.

I tried to find this proposal but the links don't work, once upon a time it was 2795 "Erroneous Behaviour". Maybe the author asked that it be withdrawn for some reason?

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#43

Post by ot »

rightbyte wrote: post #5

I feel things with C++ are not as bad as with Python, but I would really like a "core language freeze" for 10 years now or something. I don't want to keep up with all these changes. To many enthusiasts on the committee.

It is a very fortunate coincidence that C++ reached the ideal feature set right around the time I learned it.

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#44

Post by tialaramex »

jmgao wrote: post #39
lifthrasiir wrote: post #32

Earlier quoted context omitted.

> While more modern languages benefit from the errors of the older ones, I do not think they will be exempt from this kind of responsible growth process when they will become decades old. This is true, but C++ hasn't learned enough from other languages' experiences either. Let's assume that `_` couldn't not be introduced without breaking changes. Even in that case it would be reasonable to opt in that syntax for some…

> Even in that case it would be reasonable to opt in that syntax for some blocks of code, without breaking any existing code which hasn't opted in, and this "edition" mechanism was very successful to evolve syntaxes and often semantics in recent languages (JS, Rust, ...). You can't really do this in a language where the way you use libraries is by textual inclusion of headers which can include arbitrary code (no one…

The proposal (Epochs) to do this in C++ even says it needs modules. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p18...

It would have been extremely difficult to do this for say C++ 20 even if the other work was abandoned (which IMO would have been sensible) and I feel confident it is now impossible.

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#45

Post by riffraff »

rightbyte wrote: post #24
riffraff wrote: post #10

Earlier quoted context omitted.

What new language features did python get recently that make it harder for newbies?

I can't think of any specifics that won't sound silly in isolation. It is just the sum. I mean, it felt like I woke up one day and couldn't read Python anymore. I believe there is a great lag between introduction of a concept/syntax/whatever and its actual use, so I can't even pinpoint a version where Python became "too much".

thanks, I believe I get what you're saying, as a python outsider I just could not think of the changes :)

Typing syntax and pattern matching look pretty significant changes, but nothing else bug comes to mind. I guess ternary expressions and perhaps f-strings are new too but not very big

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#46

Post by eesmith »

dthul wrote: post #33
muxator wrote: post #27

> Some compiler needs to implement -Wunderbar Hidden gem! On a more serious note, the author of this little proposal (officializing "_" as a no name placeholder) had to perform a thorough research to show that this change would not break existing code. This kind of attention is necessary for a language with broad scope and a long successful history such as C++, and would be for every other language with such characte…

There is an interesting approach to this in Rust: if a potentially breaking change (e.g. a soundness fix) is being proposed, they usually test it against all publicly available Rust code.

I'm not sure that's the flex you think it might be.

At least, I interpret it as saying there isn't much publicly available Rust code, and only a few places to find Rust code.

I have a hard time even estimating how long it would take to test a change against all publicly available C++ code.

FWIW, the C++ standards developers use do use code search tools to help identify possible breakage.

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#47

Post by paulmooreparks »

staunton wrote: post #28

I still think they should stop adding new features and do what the C committee does in keeping the language stable over the decades which it will take to slowly die, as it should. Can't the new-feature enthusiasts just make a new language, or join existing efforts at building new ones? C++ is already a mess of around 3.5 languages jumbled together. When will it stop?

Herb is working on something like that already. See his work on CppFront as an alternative syntax for C++: https://github.com/hsutter/cppfront

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#48

Post by gkedzierski »

ot wrote: post #43
rightbyte wrote: post #5

I feel things with C++ are not as bad as with Python, but I would really like a "core language freeze" for 10 years now or something. I don't want to keep up with all these changes. To many enthusiasts on the committee.

It is a very fortunate coincidence that C++ reached the ideal feature set right around the time I learned it.

100% agree, C++98 was amazing :)

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#49

Post by lifthrasiir »

jmgao wrote: post #39
lifthrasiir wrote: post #32

Earlier quoted context omitted.

> While more modern languages benefit from the errors of the older ones, I do not think they will be exempt from this kind of responsible growth process when they will become decades old. This is true, but C++ hasn't learned enough from other languages' experiences either. Let's assume that `_` couldn't not be introduced without breaking changes. Even in that case it would be reasonable to opt in that syntax for some…

> Even in that case it would be reasonable to opt in that syntax for some blocks of code, without breaking any existing code which hasn't opted in, and this "edition" mechanism was very successful to evolve syntaxes and often semantics in recent languages (JS, Rust, ...). You can't really do this in a language where the way you use libraries is by textual inclusion of headers which can include arbitrary code (no one…

That's a bad excuse. In fact I think editions are possible without modules at all, if you are really willing to fix this issue. Tying epochs to modules suggests that they don't think this is a huge issue to start with.

One possible design is to assign editions to all preprocessed tokens. This implies the edition definition should be some sort of pragma (say, `#pragma STDCXX EDITION 2023`) and preprocessors should add pragmas themselves if tokens with a different edition are transcluded into other tokens. Implementations with integrated preprocessor and parser may also use a simpler internal representation to convey editions as well. Now `_` would be a normal identifier in past editions and a placeholder in a new edition, however they are passed through macros. For example:

    #pragma STDCXX EDITION 2023
    // Hereafter `_` is parsed as `_2023` internally
    #define GUARD() auto _ = make_guard()

    #pragma STDCXX EDITION 2020
    // Hereafter `_` is parsed as `_2020` internally
    {
        GUARD();
        GUARD();             // Okay, equivalent to `auto _2023 = make_guard();`
        foo(&_);             // Up to the proposal author, but P2169 suggests that
                             // this `_` should refer to the second `_2023`
    }
    auto _ = make_guard();   // Okay, equivalent to `auto _2020 = make_guard();`
    auto _ = make_guard();   // Nope, `_2020` can't be defined more than once in the same scope
Of course there are more questions to answer. For example what would `#` and `##` do to editions? Should the current edition reset after `#include` finishes? (I think so.) How would we compute the edition for specific syntax from constituent tokens? (A systematic approach would be to collect a set of all editions used in syntactic tokens, and if not all editions in that set result in the same result, to issue an error.)

But I still argue that this design is simple, checks all checkboxes as long as open questions are decided, and can be independently deployed. And this token-level tracking is not something alien, it's required to give more accurate diagnostics anyway---and other languages like Rust have even used it to implement things like macro hygiene.

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#50

Post by lifthrasiir »

eesmith wrote: post #46
dthul wrote: post #33

Earlier quoted context omitted.

There is an interesting approach to this in Rust: if a potentially breaking change (e.g. a soundness fix) is being proposed, they usually test it against all publicly available Rust code.

I'm not sure that's the flex you think it might be. At least, I interpret it as saying there isn't much publicly available Rust code, and only a few places to find Rust code. I have a hard time even estimating how long it would take to test a change against all publicly available C++ code. FWIW, the C++ standards developers use do use code search tools to help identify possible breakage.

Note that this tool (crater) is mainly used to catch regressions, not to judge whether it's worth to intentionally break things (which is what editions are for). If many crates depend on the bug which devs want to fix crater will probably detect that and devs will consider other alternatives.
Post reply on HN