Implicit Casts vs the (maybe `(void*)`) Waypoint Cast

A C++ developer investigating the use of (void*) casts to force correct pointer conversions found that the trick does not work in general and can silently reproduce pointer-corruption bugs. The author replaced it with an implicit_cast<T>() helper, only to discover that their actual codebase's use case was the mirror image of the scenario they had analyzed, presenting a different problem. The article details two distinct cases where C-style casts hide different overload resolution issues, concluding that the void* hop is not a reliable fix.

This is my first piece of AI-assisted technical writing. Rather than talk here about giving credit to which-LLM-did-what and date the C++ content itself to the AI boom of 202X I put some thoughts in another article: https://ae1020.github.io/ai-writing-when-to-stop/ I found myself having to explain why I kept writing T void ptr in a C++ library. I was convinced the void hop was a deliberate trick — a way to force a conversion through the “correct” path instead of an accidental wrong one. I wrote up why I thought it worked. Then, while getting the writeup reviewed, it became clear the trick doesn’t work in general: it can silently reproduce the exact pointer-corruption bug it was supposed to avoid. So I replaced it with a cleaner-looking implicit cast<T helper that sidesteps the problem by construction, and thought I could move on. Then I tried rebuilding the actual library the idiom came from, and it didn’t compile — not “silently wrong,” a hard compiler error. My codebase’s real use case turned out not to be the one I’d been writing about at all. It was the mirror image of it, and the mirror image doesn’t have the same fix. It doesn’t even have the same kind of bug. This turns into two related but genuinely different problems, both hiding behind the same-looking C-style cast — and answering “is the void version still an implicit cast?” turns out to need a real answer, not a slogan. Case 1: A Wrapper Hiding the Wrong Overload Upcasts Here’s the scenario I originally had in mind — a type with two conversions, where a direct cast picks the wrong one. The trap: a type with two conversions Suppose you have a small wrapper class that knows how to convert to its “natural” pointer type implicitly, and — as an escape hatch for generic code — also offers an explicit, templated conversion to any pointer type: template<typename T class Wrapper { T p; public: Wrapper T p : p p {} operator T const { return p; } // implicit, exact type template<typename U explicit operator U const { // explicit, any type return reinterpret cast<U p ; } }; The implicit operator is the “happy path” — it fires automatically and returns the exact pointer you’d expect. The templated explicit operator exists so that generic code templates that don’t know T at the call site can still coerce the wrapper to some related pointer type when asked directly. Now say Derived inherits from Base, and you have a Wrapper<Derived . You want a Base out of it. The obvious thing to write is: Base b = static cast<Base wrapper ; // looks right... This compiles. It also silently does the wrong thing. Overload resolution has no operator Base to reach for, so it falls back to the only conversion that can produce a Base : the templated explicit operator, with U = Base. That operator uses reinterpret cast, which does not perform base-class pointer adjustment. If Derived has a non-trivial layout relationship with Base — a second base class, a virtual base, or just a compiler that puts things in a different order than you assumed — the resulting Base can be a corrupted address, not the address static cast would have produced from an actual Derived . The bug is invisible at the call site. Nothing warns you. It compiles clean and often “works” in simple single-inheritance layouts purely by accident of address arithmetic being a no-op there. The Tempting Counter-Attack And Why It Fails The “obvious” fix looks almost too simple: Base b = Base void wrapper; The reasoning sounds solid — but it rests on a claim about overload resolution that isn’t actually true, and it’s worth pinning down now, because the same mistake comes back with real teeth in Case 2. A C-style cast to void is direct-initialization, and direct- initialization considers every conversion function, explicit or not. Explicitness only decides whether a candidate is in the running at all — it carries no weight once ranking starts. Ranking runs purely on the conversion sequence from each candidate’s return type to the target, and here the templated explicit operator has an edge the implicit one doesn’t: matching its pattern U against the target void lets the compiler deduce U = void directly, so it returns void exactly — an Identity match. The implicit operator returns Derived , which still needs an ordinary Derived - void conversion to finish the job — ranked Conversion, strictly worse than Identity. So the explicit template operator, not the implicit one, is actually the candidate that wins this contest. It happens not to matter here. Converting any object pointer to void never adjusts the address — the standard requires the value to pass through unchanged, no matter which conversion function produced the pointer being converted. So whichever operator actually fires, void wrapper ends up holding the same bits either way: the unadjusted address of the Derived object. Hop one lands on the right address by coincidence, not because “implicit beats explicit” — a belief that’s about to stop being harmless. It’s hop two that quietly ruins everything: Base void value . A C-style cast from void to a typed pointer behaves like static cast. And static cast<Base of a void is not the same operation as static cast<Base of a Derived . The standard only lets a void round-trip back into the exact object it pointed to or a pointer- interconvertible one — informally, an object at the same address, such as the first base in a standard-layout type with no vtable . Outside of that narrow case, the wording is blunt: the pointer value is unchanged by the conversion. Once the pointer has been erased to void , the compiler no longer knows the static type of the thing it came from. It has no class hierarchy to consult, no offset to apply — it just hands back the same bits it was given. If Base lives at a non-zero offset inside Derived a second base in multiple inheritance, a virtual base, anything where the base subobject isn’t at the start of the object , then Base void wrapper produces a pointer to the start of the Derived object, not to the Base subobject. That is precisely the corrupted address the templated explicit operator U produced with its internal reinterpret cast — the bug is back, just hiding behind an extra pair of parentheses that looked principled. The failure is worse than the original one in one respect: it’s much harder to spot in review. reinterpret cast at least announces “I am doing something dangerous.” void announces nothing. It reads like a type-erasure no-op, and for the single-inheritance, no-vtable case it is a no-op — which is exactly why the bug can live in a codebase for a long time before a multiple-inheritance or virtual-inheritance type walks in and breaks it. The True Fix: Force an Implicit-Only Context The actual problem was never “the type gets erased.” It’s that static cast and C-style casts perform direct-initialization, and direct-initialization is the context in which that templated explicit operator U is eligible to be chosen at all. Explicit conversion functions are excluded only from copy-initialization — the kind of implicit conversion that happens when a value is used to initialize a parameter or a return, with no cast in sight. So instead of trying to out-maneuver overload resolution with a detour through void , force the conversion into a context where the explicit operator was never a candidate in the first place: template<typename T struct type identity { using type = T; }; template<typename T T implicit cast typename type identity<T ::type val { return val; } If your standard library has std::identity, or you’re on C++20, you can use that instead of hand-rolling it. The typename type identity<T ::type wrapping around the parameter type is what makes this work: it puts T in a non-deduced context, so the compiler can’t infer T from the argument. You must supply it explicitly at the call site: Base b = implicit cast<Base wrapper ; Now trace what overload resolution actually does: T is fixed to Base before the parameter type is even considered for deduction — there’s no deduction left to do. The parameter val is of type Base , and wrapper needs to copy-initialize it. This is not a cast; it’s the same kind of implicit conversion that happens when passing an argument to any ordinary function. Because it’s copy-initialization, the templated explicit operator U is not in the candidate set at all — explicit conversion functions are never considered for copy-initialization, full stop. The only viable conversion function left is the implicit operator Derived . The compiler uses it, producing a real Derived . That Derived then needs to become a Base to finish initializing val — and this step is an ordinary derived-to-base pointer conversion, the same one static cast<Base a derived ptr would do. The compiler has the full type information at this point, so it applies whatever offset Base actually needs, correctly, in every inheritance configuration. No detour through void , no erased type, no reliance on address coincidences. The pointer adjustment happens exactly where the compiler has enough information to get it right. There’s a load-bearing assumption baked into all of this, though: step 5 only works because Derived - Base is something the language already knows how to do implicitly. implicit cast<T doesn’t manufacture a conversion out of nothing — it just clears an explicit-only competitor out of the way so that whatever implicit path already exists gets used. If no implicit path exists at all — which is exactly the situation in Case 2 — there’s nothing left for it to fall back on, and it stops compiling entirely. Case 2: When There’s No Implicit Path At All Downcasts Here’s the case that actually put T void expr in my code in the first place, and it’s the mirror image of Case 1: instead of getting a Base out of a Derived-flavored wrapper, I needed to get a Derived out of a Base-flavored wrapper. That one-word difference changes everything, because of a rule every C++ programmer learns early and then mostly forgets about: Derived - Base is a standard, implicit conversion — the compiler will do it with no cast at all. Base - Derived is never implicit, for any hierarchy, under any circumstances. It’s a downcast: you’re asserting something the static type system can’t verify on its own “I happen to know this Base is really a Derived” , so the language requires you to say so explicitly, every time. Now put a wrapper in the mix. Say you have a small handle type that runs a check whenever it’s converted to its natural pointer type — something like a debug-only “has this been validated yet” flag: template<typename T class Handle { T p; mutable bool needs check = true; public: Handle T p : p p {} operator T const { // implicit, exact type if needs check { run debug validation p ; // <- the side effect needs check = false; } return p; } template<typename U explicit operator U const { // explicit, any type return reinterpret cast<U p ; // <- no side effect at all } }; Suppose Handle<Base needs to hand back a Derived some caller has verified, out of band, that the underlying object really is a Derived . Reach for the tool that supposedly always works: Derived d = implicit cast<Derived handle ; // does not compile This fails outright — a compiler error, not a silent bug. implicit cast<T copy-initializes its parameter from handle, and copy-initialization only considers implicit conversion functions. Handle<Base has exactly one: operator Base . But Base - Derived isn’t a standard conversion, so there’s no way to complete the initialization using only implicit machinery. Overload resolution comes up empty. implicit cast<T isn’t picking the wrong overload here — it has nothing left to pick from at all. So what does a plain cast do instead? Derived d = static cast<Derived handle ; // compiles, but skips the check This compiles, for the same underlying reason it compiled in Case 1: direct-initialization what static cast and C-style casts perform does consider Handle’s templated explicit operator U , with U = Derived. Here, though, it’s not competing against anything — it’s the only viable candidate on the table. The compiler calls it, gets back reinterpret cast<Derived p , and needs check never gets cleared. run debug validation never runs. The address comes out completely fine more on that in a moment — but the entire point of routing through the implicit operator, its side effect, has been silently skipped. This is a genuinely different failure mode from Case 1. Case 1 was about getting a corrupted address from the wrong overload. Case 2 is about getting a perfectly correct address while silently skipping behavior the implicit operator was responsible for running. The Tempting Fix for Case 2 And Why It Also Fails Given Case 1’s story, the obvious move is to reach for the same two-hop idiom that Case 1 just spent a whole section warning about, on the theory that this time the roles are reversed and it’ll actually work: Derived d = Derived void handle; // looks right... It isn’t. The claim Case 1 debunked — “a C-style cast to void prefers implicit conversions” — was never true, and here it actually costs something. void handle is direct-initialization, so Handle<Base ’s templated explicit operator U is just as much a candidate as the implicit operator Base . Deducing U = void gives the explicit operator an exact-match return type of void ; the implicit operator’s Base needs an extra Base - void conversion to get there. Identity beats Conversion, so void handle calls the explicit operator — the one with no side effect at all. run debug validation never runs, needs check never clears, and the address comes out fine only because — same as Case 1 — converting any object pointer to void never needs adjustment, so the bits are identical no matter which operator produced them. This is the exact same bug as Case 1, one level further in: reaching for void on the theory that it selects the implicit conversion function, when it actually just runs an ordinary overload-resolution contest that the explicit operator happens to win whenever the target is void . Case 1 never noticed, because the winning candidate didn’t matter there — both operators land on the same address. Case 2 isn’t so forgiving, because what’s riding on the outcome is a side effect, not just an address. If you don’t want to take this on faith: put a printf in each of Handle’s two operators and watch which one actually fires for void handle. It’s the explicit one — confirmed by compiling exactly this example. The Real Fix for Case 2: Copy-Initialize First, Then Reinterpret The actual fix doesn’t route through void at all — it routes through the named intermediate type instead, using plain copy-initialization: Base validated = handle; // copy-init only Derived d = reinterpret cast<Derived validated ; // layout-proven reinterpret Step 1, Base validated = handle;. This is copy-initialization, not a cast — the same context implicit cast<T relies on in Case 1. Copy-initialization doesn’t rank explicit candidates worse than implicit ones; it removes them from the candidate set unconditionally, before any ranking happens at all. There’s no U = void deduction to win a contest with, because Base is a concrete named type, not a deduced pattern — the templated explicit operator U isn’t a candidate here, full stop. The only conversion function left is operator Base , so it’s the one that runs: run debug validation fires, needs check clears, and validated holds a correctly-typed Base . Step 2, reinterpret cast<Derived validated . Now that validated is a plain, concrete Base — no wrapper, no conversion operators left to interfere — reinterpreting it as Derived is the same operation the broken Derived void handle attempt was reaching for in its second hop, with the same requirement: it’s only safe because Base and Derived are laid out so that no offset adjustment is ever needed standard-layout, matching sizeof, proven separately via static assert . Routing through void here would add nothing — Base is already a plain pointer with no operators of its own left to dodge. The void hop, in other words, was never doing the job this piece originally credited it with. That job — soliciting the implicit conversion function and nothing else — was always copy-initialization’s job. void just happened to look like it was forcing the same outcome, in a case Case 1 where the actual winning overload didn’t matter to the final bits. Once the source has a side effect that depends on picking the correct operator, void is the wrong tool for that step — copy-initialization to a named intermediate type is the only version of “solicit the implicit conversion” the standard actually guarantees. So, Is It Still an “Implicit Cast”? Given both cases, is “copy-initialize, then reinterpret” fair to call “an implicit cast”? Sort of — but not in the sense that matters most, and not for the reason this piece originally gave. What actually forces the implicit path: copy-initialization — assigning or passing the source to a variable or parameter of its own natural, concrete type. Copy-initialization unconditionally excludes explicit conversion functions from the candidate set, which is the only version of “give me the implicit conversion and nothing else” that the standard actually guarantees, rather than one that depends on how a ranking contest happens to come out. What void doesn’t reliably do: force the implicit operator to run. A C-style cast to void is direct-initialization, which admits explicit conversion functions as full candidates, ranked purely by how close their return type is to void . A templated explicit operator U can deduce U = void for an exact match, beating an implicit operator whose return type still needs an extra conversion to reach void . Whether that costs you anything depends entirely on whether more than the address rides on the outcome — invisible in Case 1, load-bearing in Case 2. What the reinterpret step doesn’t do, either way: produce a value of some type the language considers implicitly — or even explicitly — reachable from the source. There is no conversion from Handle<Base all the way to Derived . That step isn’t a conversion the type system endorses at all; it’s a raw reinterpretation of an address, whose correctness is a fact you’re required to have established independently, elsewhere, about the layout of your types. The honest mental model is: “copy-initialize to the implicit type, then reinterpret.” Calling the whole thing “an implicit cast” is fine as shorthand once you know what’s actually buying you the implicit behavior — but it’s copy-initialization doing that work, not void . void or a named reinterpret cast — they’re equally valid once the intermediate is a plain pointer only shows up in the second step, where it’s just a bit-preserving relabeling with no say in which conversion function produced the value being relabeled. When each pattern is worth reaching for implicit cast and the copy-init waypoint both work by excluding explicit conversion functions from the candidate set — they just start from opposite endpoints of the same hierarchy. Side by side, using the two example types from above: // Case 1 — Wrapper<Derived holds a pointer whose "natural" type is // Derived . Base IS implicitly reachable Derived - Base always is . // A raw static cast picks the WRONG overload; implicit cast picks the // right one on purpose. Base b1 = static cast<Base wrapper ; // WRONG: corrupted address // hits explicit operator U Base b2 = implicit cast<Base wrapper ; // RIGHT: correct address // forces operator Derived Base b3 = Base void wrapper; // WRONG: corrupted address, again // hop 2 can't adjust for offset // Case 2 — Handle<Base holds a pointer whose "natural" type is Base . // Derived is NOT implicitly reachable from Base downcasts never are . // implicit cast has nothing to select -- it fails to compile. A raw // static cast compiles, but silently skips the validation side effect. // So does the naive void waypoint -- it hits the SAME explicit // overload static cast does, for the same reason: U=void is an exact // match that beats the implicit operator's Base - void conversion. Derived d1 = static cast<Derived handle ; // COMPILES, SKIPS run debug validation // hits explicit operator U Derived d2 = implicit cast<Derived handle ; // FAILS TO COMPILE // no implicit Base - Derived Derived d3 = Derived void handle; // WRONG: ALSO skips run debug validation // explicit U=void wins the ranking Base validated = handle; // RIGHT: copy-init excludes // the explicit operator outright Derived d4 = reinterpret cast<Derived validated ; // runs run debug validation, // correct address layout-guaranteed The contrast is the whole lesson, but it’s not the one this piece first reached for. In Case 1, both static cast and the naive void cast choose the same wrong overload — the templated explicit operator U — because an implicit Base was never on offer for the wrapper’s actual conversion functions to reach; only bypassing the explicit competitor with implicit cast gets the address right. In Case 2, static cast and the naive void cast also choose the same overload as each other — for the same underlying reason, direct-initialization admitting the explicit template as a candidate and letting an exact-match deduction win. What’s different about Case 2 is that implicit cast can’t even compile, because there’s no implicit conversion for it to fall back on — which is exactly why this piece needed a different tool for Case 2: not void , but copy-initialization to the named intermediate type, which excludes the explicit candidate the same unconditional way implicit cast does. The two fixes solve non-overlapping problems, and the deciding question is: does an implicit path to the target type exist at all? Reach for implicit cast<T when it does — typically an upcast, or any case where the target type is genuinely, implicitly reachable, but a broader explicit/templated conversion on the source type would otherwise hijack a direct cast: Smart-pointer-like wrapper types that support generic coercion for template metaprogramming, alongside a normal implicit conversion. Any class hierarchy using multiple inheritance or virtual inheritance, where pointer identity is not just “the same address reinterpreted” — base subobjects can live at nonzero offsets. This is exactly the case where the void shortcut falls apart and implicit cast earns its keep. It is not needed for plain pointers to related classes Derived - Base already does the right thing with a normal static cast, no wrapper type or helper required . And it doesn’t need void at all — that’s the whole point. The fix isn’t about erasing type information; it’s about picking initialization contexts where the compiler’s overload resolution rules already do what you want. Reach for the copy-init waypoint when there’s no implicit path to the final type at all — typically a downcast, or any conversion the type system will never sanction on its own — but the source type still has an implicit conversion to some intermediate type that has a side effect you can’t afford to skip: Hand-rolled handle/wrapper types where the “natural,” implicit conversion does bookkeeping — debug validation, reference counting, poisoning, assertion checks — that a bare reinterpret cast escape hatch bypasses entirely. Any place you’re prepared to separately prove via static assert on std::is standard layout and matching sizeof, or an equivalent domain-specific guarantee that the reinterpretation in the final step needs no address adjustment. Without that proof, don’t reach for this — the reinterpret step has no safety net of its own. Note that this is not the same tool as “cast to void first.” A literal void hop is direct-initialization and admits the same explicit competitor implicit cast was invented to dodge — it just happens to matter less obviously, because the target is void rather than a named pointer type. The waypoint has to be copy-initialization to the source’s own concrete, named type; only then is the explicit operator categorically excluded. Neither tool is a general-purpose substitute for static cast. Each one exists to route around exactly one specific way a plain cast’s overload resolution goes somewhere other than where you meant. A note on naming both workarounds Whichever one applies, don’t leave it as an unnamed one-off — and don’t reach for a bare void “for symmetry” with other casts in the code when implicit cast<T was actually what the situation called for, or vice versa. Give each helper a name and keep it around as a small, reusable utility. For the copy-init waypoint, the honest implementation needs to name the intermediate type explicitly — there’s no way to deduce it generically, since it’s whatever concrete type the source’s own implicit conversion operator happens to produce: template<typename Target, typename Intermediate, typename Source Target waypoint cast const Source& src { Intermediate intermediate = src; // copy-init: implicit path only return reinterpret cast<Target intermediate ; // layout-proven reinterpret } // Derived d = waypoint cast<Derived , Base handle ; Or, if you’re stuck writing it as a macro for a C-compatible codebase, a small lambda forces the same copy-initialization context without needing a separate named helper per call site: define waypoint cast TargetType, IntermediateType, expr \ IntermediateType intermediate { \ return reinterpret cast<TargetType intermediate ; \ } expr Either form makes the name do double duty: it says what the target type is, and the explicit Intermediate parameter documents exactly which implicit conversion is being solicited, instead of leaving it to be reverse-engineered from the source type’s overload set. Visibility. A reviewer sees a named idiom — implicit cast<Base x or waypoint cast<Derived , Base x — instead of a cast expression whose purpose has to be reverse-engineered from context, or worse, misdiagnosed as the other pattern’s fix or as the broken literal void version of itself . Searchability. Every call site that depends on “give me the implicit conversion and nothing else” — for whichever of the two reasons — is one grep away, which matters if the wrapper type’s conversion operators ever change. Correctness by construction, where it applies. Both implicit cast<T and waypoint cast<Target, Intermediate work by excluding a category of overload from consideration — via copy-initialization — rather than by out-guessing which overload will fire or which one a void target happens to rank best. waypoint cast doesn’t get full correctness for free, though — its final reinterpret cast rests on a layout invariant you have to keep proving separately, so it’s worth a comment at the definition site pointing at exactly what guarantees it. Compilers are very good at doing exactly what the standard says and not what you meant. When a type has more than one way to become a pointer, the first question isn’t “which cast do I reach for” — it’s “does an implicit conversion to what I want exist at all, or am I trying to force a side effect out of a conversion I can’t actually complete.” Those are different problems, and — as it turns out — they have different fixes. Addendum: Whitelisting the Cheap Path waypoint cast<Target, Intermediate is safe by construction, but it has a real cost at every call site: you have to name Intermediate by hand, and it forces an actual, separate copy-initialization step before the reinterpret. That’s the right price to pay when a wrapper’s conversion operators genuinely disagree — different side effects, or a side effect on one side and none on the other, the way Handle does above. But that’s not the only shape a wrapper’s conversion operators come in. Plenty of wrapper types offer several conversion paths that all just hand back the same bits with the same side effects — an implicit “natural type” operator and an explicit “generic escape hatch” operator that happen to agree on everything, because one is a thin pass-through to the other, or neither does anything but return a field. For those types, it provably does not matter which conversion function void picks, and a bare, single- step Target void expr is both correct and cheaper to write than naming an intermediate type at every use. The catch is that “provably does not matter” is a claim about the type, not about any individual cast expression — and it has to be re-verified by a human every time that type’s operators change. Leaving that judgment silently implied at each call site is exactly how this article’s original bug got written in the first place. So instead of trusting each call site, push the claim into a single, explicit, opt-in declaration attached to the type itself, and have every use of the cheap path check it automatically at compile time: // Nothing is safe by default -- only raw pointers, which have no competing // conversion operators to race in the first place. template<typename T struct VoidWaypointSafe : std::is pointer<T {}; // Opt a specific wrapper in, immediately next to its own definition, with a // comment justifying the claim: // // Every conversion path PtrWrapper offers returns the same address with // no side effects of its own, so it doesn't matter which one void // picks. // template<typename T struct VoidWaypointSafe<PtrWrapper<T : std::true type {}; template<typename T struct VoidWaypointSafeChecker { static assert VoidWaypointSafe<T ::value, "void waypoint cast : T not vouched safe -- see VoidWaypointSafe" ; }; // Forces a template to be instantiated and any static assert inside it to // run purely at compile time, with zero runtime cost -- sizeof never // evaluates its operand. define DUMMY INSTANCE ... static cast<void sizeof VA ARGS define void waypoint cast TargetType, expr \ DUMMY INSTANCE VoidWaypointSafeChecker< \ typename std::remove cv<typename std::remove reference< \ decltype expr ::type ::type , \ TargetType void expr The comma operator is doing the real work here: the left side of A, B is evaluated at compile time only, in this case purely for its checking side effect, then discarded, and the expression’s value is B — the plain void cast, completely unchanged at runtime. sizeof never evaluates its operand, so DUMMY INSTANCE costs nothing at runtime either; all it does is force the compiler to instantiate VoidWaypointSafeChecker<T for whatever T the expression actually has, which is what triggers the static assert — and a failed static assert is a compile error, not a debug-build check that a release build quietly skips. Any type that hasn’t been or is no longer vouched for fails to compile, by name, at the exact call site that used it — there is no path where an unvetted type silently reaches the cast. This is deliberately a whitelist, not a detector: nothing here inspects a type’s operators and decides for itself whether they agree. That judgment has to be made once, by a person, sitting next to the type’s own definition, as a small and auditable claim “every conversion path this type has returns the same address with the same side effects” . Get that claim wrong and this reintroduces the exact bug the rest of this article is about — just laundered through a trait that looks like a safety check. So it earns its keep only when the claim is genuinely trivial to verify by reading the type once, and it should stay rare and deliberate rather than becoming the default way of avoiding waypoint cast<Target, Intermediate ’s extra typing.