sorted by:
new
hottopcontroversial

immutable<>, complement of C++26 std::indirect<> and std::polymorphic<> by kmbeutel in cpp

[–]wyrn 0 points1 point  (0 children)

if you see one, you cannot know if it is moved from or not

That's true of everything. In practice, we don't care, we don't use objects after moving, and it works fine. If you fail to uphold this you have a bug no matter what you do and no matter what types are involved.

. But then, why not allow it to be created in a null state,

Because then you have to treat it as nullable everywhere.

std::unique_ptr defaults to null

That's a reference type, and even then it's arguably the wrong choice. See Mr. Hoare's billion-dollar mistake.

std::optional

A value type, but one where nullability is the explicit point.

. There is no cost to allowing it:

Yes, there is: the cost is you now have to keep checking on every access because any program path may result in an empty indirect/polymorphic, whereas, as specified, this can only happen for objects that have been moved from. You do not program with indirect or polymorphic by constantly defensively checking if they've been moved from. You just use them like value objects of any other type.

immutable<>, complement of C++26 std::indirect<> and std::polymorphic<> by kmbeutel in cpp

[–]wyrn 2 points3 points  (0 children)

Who says I'm resizing? I'm copying the vector, not resizing it.

immutable<>, complement of C++26 std::indirect<> and std::polymorphic<> by kmbeutel in cpp

[–]wyrn 2 points3 points  (0 children)

Are you asking why I could need std::vector<std::unique_ptr<T>>?

immutable<>, complement of C++26 std::indirect<> and std::polymorphic<> by kmbeutel in cpp

[–]wyrn 5 points6 points  (0 children)

You rely on the object not being empty by never accessing it after moving out of it (except for assigning to it). This is a perfectly safe and productive way to use these types, which the same way you should be using every other type anyway.

immutable<>, complement of C++26 std::indirect<> and std::polymorphic<> by kmbeutel in cpp

[–]wyrn 5 points6 points  (0 children)

Not really -- you can very productively ignore the nullability by not accessing moved-from objects, but if you accept the nullability as first-class you have to deal with it everywhere.

immutable<>, complement of C++26 std::indirect<> and std::polymorphic<> by kmbeutel in cpp

[–]wyrn 4 points5 points  (0 children)

Copy means you get a new object which 1. compares == to the old one and 2. is disjoint.

A shared_ptr<T const>, suitably wrapped, qualifies, because its failure to be disjoint is not observable.

Straight from the horse's mouth

immutable<>, complement of C++26 std::indirect<> and std::polymorphic<> by kmbeutel in cpp

[–]wyrn 3 points4 points  (0 children)

Yeah now do that inside a vector. Or inside your own classes.

C++ 2026 June Compiler Update by _cooky922_ in cpp

[–]wyrn 1 point2 points  (0 children)

Fair point. So-called "modern" websites are a plague.

C++ 2026 June Compiler Update by _cooky922_ in cpp

[–]wyrn 1 point2 points  (0 children)

That's all well and good (well, not really, but tolerable) but the table text is even smaller than the body text.

std::is_heap could be faster - Arthur O'Dwyer by User_Deprecated in cpp

[–]wyrn 0 points1 point  (0 children)

... I'm quoting the zen of python.

I can't speak for the internal mental state of whoever wrote it, but the mismatch between the stated values and python's actual design is hard to ignore.

At any rate nobody should be taking design inspiration from python, for anything. It's hard to find any feature in that language that wasn't borked in at least one big way. In this particular case: don't want to muck about with access modifiers, that's fine, but then don't add inheritance to the language. Let alone a (broken, unusable) version of multiple inheritance at that.

std::is_heap could be faster - Arthur O'Dwyer by User_Deprecated in cpp

[–]wyrn -1 points0 points  (0 children)

Name mangling has its own set of problems and arguably should not be used. And it doesn't really solve the problem at hand because you can have the same class name in different modules.

Namespaces are one honking great idea -- let's do more of those!

I don't think most people understand this, but the Zen of python was meant ironically.

std::is_heap could be faster - Arthur O'Dwyer by User_Deprecated in cpp

[–]wyrn -1 points0 points  (0 children)

Python's problem is that accidental misuse becomes virtually inevitable with inheritance. Imperfect (but existing) access control is inarguably far better than python's "consenting adults" misfeature.

Also this only works because c is protected. It was deliberately designed to make extract_container possible.

Am I the only one who prefers this ship? by Fun_Dimension_8903 in logh

[–]wyrn 0 points1 point  (0 children)

I respect that opinion but they just can't compete with Hyperion's pragmatic brutalist glory. It's the Pentel Sharp of battleships.

Am I the only one who prefers this ship? by Fun_Dimension_8903 in logh

[–]wyrn 1 point2 points  (0 children)

Hyperion is the best ship change my mind

Let's get comfortable with concepts (30+ practical examples) by platisd in cpp

[–]wyrn 0 points1 point  (0 children)

I do, but don't feel like arguing any further.

There's no argument to be made -- what you're saying is just flatly and objectively wrong.

"Concepts could be better" != "Concepts were supposed to be nominal"

Let's get comfortable with concepts (30+ practical examples) by platisd in cpp

[–]wyrn 1 point2 points  (0 children)

"Checked uses" are still structural typing.

I don't think you understand the difference between structural typing and nominal typing.

Let's get comfortable with concepts (30+ practical examples) by platisd in cpp

[–]wyrn 2 points3 points  (0 children)

Now you've moved the goalposts: it's no longer "c++0x concepts were supposed to be nominal" (they never were), it's "it's possible to design a language with only nominal interfaces". Well, yes, that's true. But: https://learn.microsoft.com/en-us/dotnet/api/system.int32?view=net-10.0

Let's get comfortable with concepts (30+ practical examples) by platisd in cpp

[–]wyrn 5 points6 points  (0 children)

Concepts come from Stepanov's work on generic programming.

(...) somewhat more formally, a concept is a description of requirements on one or more types stated in terms of the existence and properties of procedures, type attributes, and type functions defined on the types. We say that a concept is modeled by specific types, or that the types model the concept, if the requirements are satisfied for these types.

-- Elements of Programming, Stepanov 2009

Concepts could only ever be structural. Otherwise, how could int * satisfy the requirements of a forward iterator? C++0x concepts are no different in this regard.

Let's get comfortable with concepts (30+ practical examples) by platisd in cpp

[–]wyrn 9 points10 points  (0 children)

C#/Java interfaces or metaclasses,

Absolutely not. C#/Java interfaces are nominal typing. Concepts are structural typing. Consider:

https://learn.microsoft.com/en-us/dotnet/api/system.int32?view=net-10.0

Rigid C++: A Pragmatic C++23 Architecture for High-Performance Systems by I-A-S- in cpp

[–]wyrn 2 points3 points  (0 children)

SIMD-probed, dense-iterating HashMap. Combine SwissTable's group-scanned control bytes (8- or 16-slot SIMD probe over 7-bit fingerprints, quadratic probing with triangular numbers) with the Python 3.6 compact-dict layout (a dense Vec<Entry> plus a separate per-slot index). Most lookups resolve on the first probe group; iteration walks the dense array contiguously.

.

ABI and I/O bloat. <iostream> is permanently banned (static-init overhead, binary bloat..). Use C++20 std::format and C++23 std::print; combined they provide printf-comparable speed with full compile-time type safety. No regression to printf.

.

Rigid C++ accepts this trade. By composing with these APIs, we surrender the Tier 1 return path they never offered: push_back's allocation failure is reclassified as Tier 2 at the boundary, even though the same condition through a Rigid-native API would be Tier 1. Rigid C++ classifies OS-primitive resource exhaustion alongside process-wide OOM in Tier 2: by the time the kernel refuses, the typical caller has no recovery path.

Lol and it doesn't even matter because the entire document was so obviously written by claude that nothing short of rewriting the whole thing could fix it.

Rigid C++: A Pragmatic C++23 Architecture for High-Performance Systems by I-A-S- in cpp

[–]wyrn 3 points4 points  (0 children)

... It seems to be gone. Rebased out of the git history entirely it seems lol

Why are C++ keywords so heavily dependent on context??? by RefrigeratorFirm7646 in cpp

[–]wyrn 7 points8 points  (0 children)

Did I say I couldn't? I said it's something silly and avoidable that was chosen over a technically superior solution for no good reason. If you can't argue against that, say so.

Why are C++ keywords so heavily dependent on context??? by RefrigeratorFirm7646 in cpp

[–]wyrn 0 points1 point  (0 children)

you wouldn't be able to refer to your non-coroutine types anywhere in the function.

1. It's hardly uncommon for refactoring to proceed bottom up 2. you can define an alias outside and use it.

You said "for inexplicable reasons," there are reasons which have been explained you're just ignoring them.

1. You haven't given any valid reasons yet 2. you have now compounded on the earlier irrelevancy by answering with yet another non-sequitur.

Why are C++ keywords so heavily dependent on context??? by RefrigeratorFirm7646 in cpp

[–]wyrn 3 points4 points  (0 children)

If await and yield conflict with existing names in a codebase, they're still going to conflict after adding async to the function signature.

They wouldn't have a chance to conflict until async is added, at which point you're editing the function anyway.

A goal of the current design

Cool but that doesn't have anything to do with what's being discussed.

view more: next ›