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

F-strings for C++26 proposal [pdf]

open-std.org

Post reply on HN
Print view View original

121–130 of 216 posts

Re: F-strings for C++26 proposal [pdf]

#121

Post by lifthrasiir »

orf wrote: post #99
ggm wrote: post #34

I'm going to make an asinine prediction. We will be exploring F-strings in future languages in 100 years time, encountering the same problems and questions. I still use printf semantics in Python3 despite trying to get with the program for symbolic string/template logic. I don't need to be told it's better, I need some Philip-K-Dick level brain re-wiring not to reach for "%d things I hate about f-strings\n" % (int(ma…

FYI that code sample is broken, it should be `(int(many()),)` Ironic I guess?

It's not broken (try it!). Any value is interpreted as an implicit 1-tuple if it's not a tuple nor a dict. A better example would have been `"..." % many()` where `many` returns a tuple or dict.

Re: F-strings for C++26 proposal [pdf]

#122

Post by tsimionescu »

a_t48 wrote: post #107
tsimionescu wrote: post #101

Earlier quoted context omitted.

And yet most if not all of the standard library keeps using pointer or reference arguments, not the new smart pointers that would actually document the ownership semantics.

Most arguments to standard library calls don't need to take ownership over memory, using a raw pointer or (const) reference is correct. Generally - smart pointers to designate ownership, raw pointers to "borrow".

If a function takes a raw pointer, you need to check the docs to know if it is taking ownership or not. There is no general rule that applies to the whole of std that functions taking raw pointers assume that they are borrowing the value.

And even if you could assume that pointer parameters represent borrowing, they are definitely not guaranteed to represent scoped borrowing: the function could store them somewhere, and then you end up with other issues. So shared_ptr is the only solution if you care about safety to represent a borrowed pointer. And of that's too costly, but the std designers did care about safety, they could have introduced a std::borrowed_ptr that is just a wrapper around T* but that is used uniformly in all std functions that borrow a pointer and guarantee not to store it.

Re: F-strings for C++26 proposal [pdf]

#123

Post by bregma »

rerdavies wrote: post #80
darknavi wrote: post #38

Earlier quoted context omitted.

Designated initializers are so nice. Even though they have C++-isms like required order, it adds safety and readability to code.

The safety and readability are nice; but WHY do they have to be in order? That is so typically clueless. Such an obvious feature, screwed up in a way that only a C++ committee member could.

Why does construction and destruction order need to be deterministic?

Well, consider what would happen if you had members whose value depends on other members. For example, one member is a pointer to another. Or perhaps one member uses RAII to hold a lock and another controls a resource.

Deterministic construction and destruction order is a fundamental feature of C++. Calling it clueless is just an indication one does not know C++.

Re: F-strings for C++26 proposal [pdf]

#124

Post by serbuvlad »

kringlezz wrote: post #117
blux wrote: post #74

Earlier quoted context omitted.

This is becoming such a tiresome opinion. How are concepts fixing a problem created by previous features to the langue? What about ranges? Auto? Move semantics? Coroutines? Constexpr? Consteval? It is time for this narrative to stop.

Move semantics is only needed because C++ introduced implicit copies (copy constructor) and they of course fucked it up my making them non-destructive so they aren't even 'zero cost'. Constexpr and consteval are hacks that 1) should have just been the default, and 2) shouldn't even be on the function definition, it should instead have been a keyword on the usage site: (and just use const) int f() { ... } // any old r…

Eh not really accurate because C's const means immutable not actually constant. So I get introducing constexpr to actually mean constant. But, yeah, constexpr x = f() should probably have worked as you described.

Re: F-strings for C++26 proposal [pdf]

#125

Post by tsimionescu »

saagarjha wrote: post #105
tsimionescu wrote: post #97

Earlier quoted context omitted.

Tell that to the designers of the C++ standard library, and the new features being added. They're the ones that keep adding new features that depend on references and pointers instead of std::shared_ptr or std::unique_ptr.

I think one problem here is that a lot of codebases have their own smart pointers and unfortunately the only currency type is the unsafe one :(

I don't think this is the only reason. If it were, they could easily have added overloads that work with both std smart pointers and with plain pointers for compatibility. Or they could add pointer type template parameters, maybe with concepts for the right ownership semantics.

Re: F-strings for C++26 proposal [pdf]

#126

Post by blux »

kringlezz wrote: post #117
blux wrote: post #74

Earlier quoted context omitted.

This is becoming such a tiresome opinion. How are concepts fixing a problem created by previous features to the langue? What about ranges? Auto? Move semantics? Coroutines? Constexpr? Consteval? It is time for this narrative to stop.

Move semantics is only needed because C++ introduced implicit copies (copy constructor) and they of course fucked it up my making them non-destructive so they aren't even 'zero cost'. Constexpr and consteval are hacks that 1) should have just been the default, and 2) shouldn't even be on the function definition, it should instead have been a keyword on the usage site: (and just use const) int f() { ... } // any old r…

Could have been if backwards compatibility was not a thing indeed.

Move constructors are not needed, they don't solve a 'problem', but improve on previous semantics.

Re: F-strings for C++26 proposal [pdf]

#127

Post by TuxSH »

derriz wrote: post #77
qalmakka wrote: post #46

Earlier quoted context omitted.

C++20's concepts IMHO are a massive update over C++11. You can basically remove almost 90% of inheritance with them without incurring in any issue (you could do that earlier too, but at the expense of incredibly hard to read error messages - now that's basically solved thanks to concepts).

I don't find the error messages produced by concepts much better than old school template errors. Maybe I got used to the latter with experience and definitely the compilers got better at generating useful error messages for templates as the years passed. On the other hand when I have to review code where a significant portion of the source relates to concepts, my heart sinks. In my opinion, C++ "concepts" are the le…

> In my opinion, C++ "concepts" are the least useful C++20 addition to the language - awful syntax, redundancy everywhere (multiple ways of writing the same thing).

They're not the least useful C++20 addition, in fact they're amongst the most useful ones.

In particular the addition of the "requires" expression is the real killer here.

> And for what? Potentially better error messages?

Removing even more enable_if and making template code even easier to read (you could do some of that with if constexpr + static_assert in C++17, but there were gotchas). Oh and it allows you to check for the presence of members in classes, which you couldn't do before.

Re: F-strings for C++26 proposal [pdf]

#128

Post by OskarS »

kringlezz wrote: post #117
blux wrote: post #74

Earlier quoted context omitted.

This is becoming such a tiresome opinion. How are concepts fixing a problem created by previous features to the langue? What about ranges? Auto? Move semantics? Coroutines? Constexpr? Consteval? It is time for this narrative to stop.

Move semantics is only needed because C++ introduced implicit copies (copy constructor) and they of course fucked it up my making them non-destructive so they aren't even 'zero cost'. Constexpr and consteval are hacks that 1) should have just been the default, and 2) shouldn't even be on the function definition, it should instead have been a keyword on the usage site: (and just use const) int f() { ... } // any old r…

I agree that I would have preferred destructive moves, but move semantics makes C++ a much richer and better language. I kinda think pre-move semantics, C++ didn't quite make "sense" as a systems programming language. Move semantics really tied the room together.

    const int x = f(); // this is always get evaluated at compile time, (or if it can't, then fail to compile)
That's very silly. You're saying this should fail to compile?

    void foo(int x) {
        const int y = bar(x);
    }
There's no way the compiler can run that, because it doesn't know what x is (indeed, it would have a different value every time you run the function with a new argument). So your proposal would ditch const completely except in the constexpr case, everything runtime would have to be mutable.

So you respond "well, I didn't mean THAT kind of const, you should have a different word for compile-time constants and run-time non-mutability!" Congratulations, you just invented constexpr.

There are many bad things about C++, but constexpr ain't one of them.

Re: F-strings for C++26 proposal [pdf]

#129

Post by neonsunset »

pjmlp wrote: post #114
cylemons wrote: post #112

Earlier quoted context omitted.

C# has a lot of features but most of them feel like simple syntactic sugar that make the language a joy to use and they interact nicely together. C++ has lots of features that interact with each other in unexpected ways that could leak memory or access freed memory etc.

C# has already enough material for pub Quiz, and no, not all of them are syntatic sugar, and require deep knowledge of the .NET runtime, and the way it interacts with the host platforms. I imagine you never went too deep into unsafe, cross language interop, lambda evolution since the delegate days, events infrastructure, pluggable GC, RCW/CCW, JIT monitoring, the new COM replacement, how the runtime and language feat…

There is no need to just throw keywords around.

For other readers - more than half of these are irrelevant.

Writing general purpose application code rarely involves thinking about implications of most of these (save for NAOT as of lately I suppose).

Writing systems C# involves additional learning curve, but if you are already familiar with C++, it comes down to understanding the correct mapping between features, learning strengths and weaknesses of the compiler and the GC and maybe doing a cursory disassembly check now and then, if you care about it.

Re: F-strings for C++26 proposal [pdf]

#130

Post by jlokier »

serbuvlad wrote: post #124
kringlezz wrote: post #117

Earlier quoted context omitted.

Move semantics is only needed because C++ introduced implicit copies (copy constructor) and they of course fucked it up my making them non-destructive so they aren't even 'zero cost'. Constexpr and consteval are hacks that 1) should have just been the default, and 2) shouldn't even be on the function definition, it should instead have been a keyword on the usage site: (and just use const) int f() { ... } // any old r…

Eh not really accurate because C's const means immutable not actually constant. So I get introducing constexpr to actually mean constant. But, yeah, constexpr x = f() should probably have worked as you described.

const is different in C++ from const in C. const variables in C++ are proper compile-time constants. In C they are not (the nearest equivalents are #define and enum values).

So in C++ "const x = EXPR" would make sense to request compile-time evaluation, but in C it wouldn't.

Post reply on HN