I'm hoping the next version gets the walrus operator.
F-strings for C++26 proposal [pdf]
191–200 of 216 posts
Re: F-strings for C++26 proposal [pdf]
#192Earlier quoted context omitted.
But there is no Arguments::fmt ? Are you thinking of the implementations of Debug::fmt and Display::fmt on Arguments ? Trait implementation isn't the same kind of thing at all.
There is exactly one useful thing you can do with an `Arguments` object: call `.fmt()` on it. The whole reason for std::Arguments very existence is to call `std::Arguments::fmt` on it. `.fmt()` is a trait implementation, but that doesn’t change anything (not sure what “kind of thing” refers to here). It’s still a function on std::Arguments.
I think you're quite muddled about what's going on here
The full name of this type is std::fmt::Arguments not std::Arguments and even so there's no such thing as std::fmt::Arguments::fmt - there is no function with that name, we can only talk about this name (since it doesn't exist) if we bring into context a specific trait such as Display or Debug
So the full name of the thing you think is the "one useful thing you can do with Arguments" is
::fmt
or perhaps it's
::fmt
... as I said, Arguments implements both traits, and their sole function has the same name so we need to disambiguate somehow if we mean one of these functions or the other. For the function defined on Arguments itself, as_str, it's already unambiguous.
In the end the Debug and Display traits are all just ductwork, which is why as_str caught my attention.
Re: F-strings for C++26 proposal [pdf]
#193Earlier quoted context omitted.
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, lear…
Many of those keywords as you call it, are part of a technical interview in any .NET consulting shop worth their business. And while I expect any junior not to know half of them, anyone claiming to be a senior better have an answer, regardless of what I throw at them. Naturally I don't expect anyone versed in desktop frameworks to master backend and vice-versa, but they better know the bits that relate to desktop in…
[deleted]
Re: F-strings for C++26 proposal [pdf]
#194So, the f-string in Python is "spelled" that way because another leading character was the only ASCII syntax left for such a thing. It's odd that PRQL and now potentially C++ might copy it. In the PRQL case it was a new thing so they could have chosen anything, double quotes (like shell interpolation) or even backticks, that seem to make more sense. Also the f- prefix was supposed to be short for format and pronounce…
We could introduce g-strings instead.
Re: F-strings for C++26 proposal [pdf]
#195Reflection is going to change things so much.
Unfortunately reflection as currently proposed is insufficient to implement string interpolation.
Re: F-strings for C++26 proposal [pdf]
#196Earlier quoted context omitted.
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.
That would be too complex. I don't think C++ developers would be able to handle it
Re: F-strings for C++26 proposal [pdf]
#197Earlier quoted context omitted.
>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,…
> "preventing themselves from accidentally mutating a variable" (when has that ever happened?) I can't count the number of times I've seen someone new to the language use map::operator[] without realizing that it's a mutating operation.
map::operator[] should just be [[deprecated]] - even if you want to mutate the map it's probably not the best way to do what you want.
Re: F-strings for C++26 proposal [pdf]
#198So the f-string literal produces a basic_formatted_string, which is basically a reified argument list for std::format, instead of a basic_string. This allows eg. println to be overloaded to operate on basic_formatted_string without allocating an intermediate string std::println("Center is: {}", getCenter()); std::println(f"Center is: {getCenter()}"); // same thing, no basic_string allocated In exchange we have the fo…
C++ desperately needs a solution for wrapper types that should eagerly decay into the wrapped type unless you pass it somewhere that explicitly wants the wrapper type.
Re: F-strings for C++26 proposal [pdf]
#199Earlier quoted context omitted.
What are the examples to std functions that uses a raw pointer but does not borrow/expects pointer to be valid past the function call?
The fact that you have to ask that question makes GP's point. There's no way to tell that from looking at a function's interface at present.
The fact that you don't have an answer make's GP's point. This isn't actually a problem with the standard library because the semantics are clear.
Re: F-strings for C++26 proposal [pdf]
#200Earlier quoted context omitted.
Off the top of my head, C++17 brought slicker notation for nested namespaces, digit separators for numeric literals (so you can more easily read 1'000'000'000), improvements in type deduction for pairs / tuples (so std::make_pair / make_tuple are basically unnecessary now), guarantees in the standard for copy elision / return value optimization in specific circumstances,. Oh, and structured bindings (so you can now w…
17 is worth it for std::filesystem alone. It also has optional and variant.
std::filesystem is useless because like so many platform abstractions it doesn't handle the last 1% correctly.
IMO the C++ standard should focus platform-agnostic functionality and leave the nitty gritty platform interaction to standalone libraries that can be patched and/or replaced as needed.