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

131–140 of 216 posts

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

#131

Post by OskarS »

jlokier wrote: post #130
serbuvlad wrote: post #124

Earlier quoted context omitted.

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.

They absolutely are not. Look at this range for-loop:

    for (const auto item: vec) { ... }
`item` is not a compile-time constant. It's different every run of the loop.

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

#132

Post by kringlezz »

OskarS wrote: post #128
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…

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…

>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.

Yeah, I see no problem with that. Non-constant expressions usage of 'const' has always just seemed like a waste of time for me, never found it useful. But I guess a lot of people really liking typing const and "preventing themselves from accidentally mutating a variable" (when has that ever happened?), so as a compromise I guess you can have a new keyword to force constant expressions:

  constexpr auto x = foo(); // always eval at compile time
  const auto x = foo(); // old timey const, probably runtime but maybe got constant folded.
but it's not really a big deal what they keyword is, the main point was that "give me a constant value" should be at the usage site, not at the function definition.

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

#133

Post by gpderetta »

3836293648 wrote: post #60
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).

C++ concepts are a failure due to them only checking one side of the contract. And the other is basically impossible to implement without breaking other parts of the language

concepts finally allowed retiring stupid SFINAE tricks. They are a huge success if only for that.

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

#134

Post by gpderetta »

ryandrake wrote: post #27
dgfitz wrote: post #19

Somehow I manage to get by just fine with c++11. I have refactored more than a few codebases that use 17 or greater. Strangely, the codebase became more maintainable afterwards.

Came here to post the same thing. C++11 was a major and practical step up from previous versions. I haven't seen anything in future standards that looked like it a tool I'd use day-to-day building actual production software. Much of the subsequent versions added things probably interesting to compiler and language academics. "Default constructible and assignable stateless lambdas?" Really?

> "Default constructible and assignable stateless lambdas?

this comes up surprisingly often.

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

#135

Post by hnlmorg »

pjmlp wrote: post #116
hnlmorg wrote: post #96

Earlier quoted context omitted.

Then we'd be supporting a different language that shares the same or similar ideals as Rust. Whether that's something already in existence or something entirely new. Rust isn't really that unique, there are plenty of other safe languages out there. And if Graydon was alone in wanting something like Rust then Rust wouldn't have grown in popularity like it has. Rust exists because enough people thought there was a need…

Rust was helped by being a Mozilla language, and some of the personalities it had around it. The big plus of the language was proving that Cyclone ideas to improve C, from AT&T research project were sound and could be made mainstream. And now other languages are building on it as well, that is why Swift, Chapel, Haskell, OCaml, D are also having a go at a mix of linear types, affine types and effects. However many fo…

> Rust was helped by being a Mozilla language, and some of the personalities it had around it.

Indeed. But my point is there was already widespread movement behind building a programming language. So if Mozilla hadn’t taken charge then I’m certain someone will.

My point is that Rust was born from a wider desire for change rather than that desire existing because of Rust. Thus that desire would have been met in one form or another regardless of the invention of Rust.

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

#136

Post by eqvinox »

beeforpork wrote: post #104

It would be nice to take care to allow the use of GNU gettext() or any other convenient translation tool. Recap: _("foo %s") macroexpands to gettext("foo %s"), then "foo %s" is extracted to a lexicon of strings by an external tool, which can be translated and compiled into .po files, which are loaded at runtime so gettext() can use a translated string based on $LC_MESSAGES. (And there is also _N(..) for correct plura…

I guess _ could be a function that both takes and returns basic_formatted_string? (I.e. not gettext()).

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

#137

Post by nurettin »

gpderetta wrote: post #108
nurettin wrote: post #103

Earlier quoted context omitted.

I thought the whole point of ranges is to solve problems created by iterators, move semantics to take care of scenarios where nrvo doesn't apply, constexpr and auto because we were hacking around it with macros (if you can even call it that)?

Iteratively improving in previously released features does not imply fixing issues caused by those features. Constexpr and auto have nothing to do with macros.

To me, redoing things that are not orthogonal implies that the older version is being fixed. Being fixed implies that it was incorrect. And to clarify, sure, auto types and constexpr are entirely new things we didn't have (auto changed meaning but yeah), but we were trying to "get something like that" using macros.

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

#138

Post by orf »

lifthrasiir wrote: post #119
orf wrote: post #93

Earlier quoted context omitted.

The most useful function is Arguments::fmt. “as_str” is just a shortcut utility function.

It is not a shortcut because it can't be implemented without knowing the `Arguments` internals. `format_args!("{}", "boo").as_str()` returns None for example.

It’s a shortcut in the sense that most, if not all optimisations are shortcuts. This one allows you to shortcut the usual formatting machinery if the result of formatting is a static string.

Like all shortcuts, it’s not something you can always rely on.

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

#139

Post by mkoubaa »

pjmlp wrote: post #49
mkoubaa wrote: post #3

Tangent: this sort of thing can be implemented without any change to libc++ (the runtime). Updates to compiler versions are sometimes postponed by users with big codebases that treat a libc++ change as something major. Why don't we see gcc or clang or msvc back porting stuff like this to an older version with a sort of future tag. It's normal to see __future__ in the python ecosystem, for instance.

Because C++, just like C, Ada, Cobol, Fortran, Modula-2, Pascal is an ISO driven language. Whereas Python language evolution is driven by whatever CPython reference implementation does. Compilers are free to do whatever they want, but then that code isn't portable.

This is also true about

#pragma once

But it became a de facto standard at some point.

thank you for the clarification. You are 100% right about the general difference. I didn't consider the level of "confidence" python has in directing it's own evolution that I don't detect in the C++ committee

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

#140

Post by mkoubaa »

wakawaka28 wrote: post #21
edflsafoiewq wrote: post #15

Earlier quoted context omitted.

f-strings are not an internationalization library.

The question was, how would you use this if you have i18n requirements. Format strings are normally part of a translation. I think the bad answer is to embed the entire f-string for a translation as usual, except this can't work because C++ f-strings would need to be compiled. The better answer is, don't use f-strings for this because you don't want translators to monkey around with code and you don't want to compile…

C++ is such a narrow skillset that I'd rather not roll the dice on translators knowing what to do
Post reply on HN