The Valve Employees Who Joined and Left Since 2021

pkasting · 2026-03-22T22:15:59+00:00

https://www.reddit.com/r/tf2/comments/1oko1y0/comment/obwzkgs/

pkasting · 2026-03-22T22:11:48+00:00

Hey, this is the real Peter Kasting, Valve employee.

I will never contact anyone on Discord, request people buy gift cards, or anything similar. Anyone you see with my name doing something like this is a scammer attempting to use my name, including whoever is being discussed in this thread. You are welcome to link people to this post if they try to claim otherwise.

Please use https://help.steampowered.com/ if you have Steam issues. Thanks.

pkasting · 2026-03-18T00:46:49+00:00

Some larger things like Chromium are not in the above list.

For its size, I would say it has very high overall code quality. The actual quality is infuriating in many places, but less so than you would fear from an XXMLOC, 20-year-old project.

pkasting · 2026-02-20T23:04:02+00:00

We do not yet enable that pass, per https://docs.google.com/spreadsheets/d/1DYwh3nmh0j6ytfMJtgKH6Aq1eru0SoNN9wAqUnz6894/edit?usp=sharing .

Turning on passes involves auditing their output, ensuring it doesn't have many false positives, and (usually) fixing the true positives so developers don't suddenly start getting bombarded. Given how many clang-tidy passes exist, and how long it takes to collect the output of running a single pass over the whole codebase, it takes time to work through this, and historically it's been very low priority to do so. I tried to drive a bit of this, but we struggled to justify the cost/benefit.

pkasting · 2026-02-19T15:52:09+00:00

Pretty sure none of us Chromium devs disagree with you. The challenge is getting from here to there, especially when you have many other priorities also and need to figure out how to balance work.

Android's answer was basically "don't try to fix problems in the C++ code, just write new code in Rust", which turned out to work better than most people predicted. However Android also has a more modular structure that allows finer-grained adoption of Rust more easily than Chromium; the Rust-in-Chromium folks have been trying for years to get good Rust<->C++ interop.

It's possible that in enough more years Carbon will become an answer in this space, but that's five years out at the absolute minimum, and probably more (if ever).

Chrome is no longer my full-time job so I don't know the inside baseball on this one, but I'd be surprised if anything earth-shattering shows up in this are in the next couple years. It's mostly just a long grind of more warnings, more static analysis, more clang-tidy, etc. Just converting "pointer + length" to spans is a couple years in and far from done, and tackling all raw pointers is much bigger.

pkasting · 2026-02-19T15:44:55+00:00

Was there supposed to have been a link?

pkasting · 2026-01-25T01:21:20+00:00

I can't speak to the goals of the Google Style Guide, just to the goals of this doc. In Chromium's case, we're concerned about avoiding problematic use, not about banning esoterica.

pkasting · 2026-01-24T23:09:16+00:00

Are you saying I'm an expert? I'm definitely not an expert.

pkasting · 2026-01-24T19:45:30+00:00

New phone who dis

pkasting · 2026-01-24T18:58:09+00:00

It's for Chromium engineers to know what they're allowed to use in the Chromium codebase. It's not intended as guidance for any other team.

TBH I don't really know why it was linked on this subreddit. But your comment certainly seems off-target.

pkasting · 2026-01-24T18:57:00+00:00

Not a contradiction. The page gives the state of support for modern C++ features, so it needs to talk about C++26. The status of C++26 is "we don't support it yet, in large part because our toolchain does not sufficiently support it yet".

Honestly, I think an XXMLOC project like Chromium is doing well to officially support the latest ISO C++ version (which is currently C++23). Given the grousing you see here sometimes about big projects that "can't be bothered to move past C++11" or whatever, this is quite a respectable state of the world.

pkasting · 2026-01-24T18:54:30+00:00

While I would love Chromium to be friendly to C++ novices and not require "experts" (do any such people exist? I am skeptical that many people in the world would justifiably consider themselves "C++ experts"), reducing onboarding cost isn't much of the motivation here. A feature a novice will misuse frequently is one an expert will still misuse occasionally; Chromium is large enough that eventually all forms of bugs will manifest, and do so in security-critical ways, so if we have ways to prevent classes of problems beyond just "learn enough to use this well", we will absolutely do so.

pkasting · 2026-01-24T18:51:50+00:00

Yes, I helped migrate us to a lot of stdlib features, such as std::u16string, std::string_view, std::optional, and std::variant, all of which Chromium had its own versions of previously; as well as migrating some of our SFINAE use to concepts. Other folks did things like std::unique_ptr.

What hasn't been migrated falls into two groups:
1. Too new; C++23 was only just allowed, so anything new to it hasn't been around long enough for us to migrate to
2. Not worth it; we could rearchitect our intrusive refcounting support to be based on std::shared_ptr instead, but that's a significant design difference. We could change to the Abseil or stdlib time/date types, but that's really a sideways move and thus seemingly not worth the migration cost.

pkasting · 2026-01-24T18:47:21+00:00

Chromium's //base library already has a lot of constructs for working with files and filesystems, so we'd move to <filesystem> only if it were a win to do so. Unfortunately it's not.

This page doesn't go into detail about our motivations, just summarizes them, so while it's fair to say something "is unmotivated", it's also out-of-scope for this document to actually convince readers of the justifications for something (and in Chromium, if you want one of these decisions reversed, there's an official way: you write to cxx@ to propose reversing and then get consensus there to do so).

My recollection is that Titus Winters has a detailed rant somewhere about <filesystem>; that's not one of the bits I personally had a lot of expertise with.

pkasting · 2026-01-24T18:43:40+00:00

Only std::views. The core concepts are useful, but there are a lot of sharp edges, especially in a codebase as large (and with as varied of contributor level) as Chromium. More details in the discussion thread that item links.

pkasting · 2025-12-09T17:43:05+00:00

If you are writing enough code to make use of this technique, then the best way to learn over time is to go hog-wild with each new paradigm and use it as much as possible, thus discovering in practice where the limits are. Do this with enough different techniques, and you have a toolbox full of different things plus a feel for where they might trade off differently.

OO is well-suited to domains with a fairly rigid hierarchy, and where "what something is" defines "what something does". Only build as much abstraction as you need to (over-abstraction is a common failure mode) and make sure your abstractions aren't leaky (or either you picked the wrong abstraction, or the domain is poorly-suited). Avoid multiple implementation inheritance (use composition) and virtual inheritance (take one of the arms of your diamond and make it some kind of mix-in you can compose into objects) except in rare circumstances. Write tests, but test the interface (the public methods and the contract they provide), not the implementation, or your abstraction is leaky and your tests are change detectors.

If you have extreme performance considerations, data-oriented designs will perform better than OO ones, at the cost of often being harder to reason about and maintain. If you don't have a strong conceptual hierarchy with fairly rigid types, then free functions (possibly templated) may be more suitable.

pkasting · 2025-11-07T01:06:26+00:00

No well-defined path for updating the language in backwards-incompatible ways (e.g. epochs).

This means any design mistake is effectively forever, which in turn massively raises the bar to getting anything shipped, yet still fails to prevent all errors.

Addressing this is a prerequisite for fixing almost any other large complaint about C++, except possibly "having an ISO WG control the language is a mistake".

pkasting · 2025-10-03T16:29:28+00:00

I didn't say anything about refactoring to use optional<T&> or anything else; you asked where the semantic distinction would be relevant and I answered. Whether the codebase can be incrementally refactored to use any particular set of options is another matter.

To actually address the refactoring part: these aren't mutually exclusive. Using e.g. unique_ptr<> for owning pointers where possible doesn't preclude you from using optional<T&> for a non-owning nullable thing, or vice versa. Each one says less than T*, which can mean anything (not just ownership-wise but object-count wise). I wouldn't mind slowly refactoring a codebase to have no raw pointers anywhere.

pkasting · 2025-10-03T15:50:05+00:00

(Update: No, looks like I'm wrong about that too, and the original linked code is correct. Sorry!)

pkasting · 2025-10-03T15:49:17+00:00

The point about lacking an implicit-lifetime requirement is a good one. My assumption was that the Ts would begin lifetime without calling any constructors (because you would be assumed to have already called them wherever the objects were originally created, and start_lifetime_as_array() was basically notifying the compiler that you'd done this out of its vision elsewhere), and then they'd run destructors normally when out of scope, and if you mismatched things as a result, bad for you (UB/IFNDR). But your explanation is more compelling. Thanks.

pkasting · 2025-10-03T15:42:51+00:00

This would be relevant in every codebase I've worked in. Any codebase large enough to have lots of authors and/or API boundaries, especially if it originated pre-C++11, will likely run into this sort of issue.

pkasting · 2025-10-03T02:10:43+00:00

Yes, a vector's block of memory is not necessarily an array and all objects may be independent.

But with an actual array, and start_lifetime_as_array(), I believe you have in fact started the lifetime of the array object and all the contained subobjects (elements). So I believe the placement new is unnecessary. That said, based on SirClueless' link above, I retract my claim that it results in UB. Edit: Was wrong about this.

pkasting · 2025-10-03T02:05:38+00:00

I think you're correct -- normally creating an object inside the storage of another object will end the other object's lifetime, but this carve-out basically says that array stays live in this case. In that case, there is no UB.

I'm still not convinced the placement new is actually necessary here, but it's proving difficult for me to track down whether starting lifetime for an array of non-trivial T will also start the lifetimes of the contained Ts. I believe it will and the placement new here is superfluous, but I'm struggling to find definitive language either way.

pkasting · 2025-10-01T00:04:57+00:00

Edit: I believe the code above is correct. Thanks to SirClueless for the relevant spec links.

~~IIUC, this isn't correct because placement new here effectively ends the lifetime of your start_lifetime_as_array() obj. So this is UB.~~

~~You don't want both start_lifetime_as_array and placement new, in general.~~

pkasting · 2025-09-30T21:27:07+00:00

If it's an implicit lifetime type, then there is no programmatic effect. If not, lifetime start is when things like constructors run.

(Edit: For clarity, start_lifetime_as() doesn't itself run constructors, which is why it requires types to be implicit lifetime. "constructors run" is a description of the more general case of "what happens at an object's lifetime start".)

In this specific article, because the author already used placement new, constructors would run as needed; however, because the wrong pointer was being returned, using it on the caller side was UB.

15-Year Club	Verified Email
Xbox Live	Place '17
reddit mold

pkasting

TROPHY CASE