AtomicString has it's own issues (for instance, unless we add it to the static string list, it's thread-hostile; otherwise, we'd need to actually hold ThreadSpecific<AtomicString> everywhere, at non-zero overhead).
If we want to make this safer, I'd rather we create a special kind of key (that's not a string), but still key by its address.
e.g.
struct SupplementKey {
const char* human_readable_;
};
// usage:
static constexpr SupplementKey key = {"NavigatorBluetooth"};
return &key;
That would at least point out that something subtle is going on. Can you point at the bad usage patterns you've seen in practice? (The linked examples look okay to me.)
From an API point of view you'd expect that a call into a supplement across complication units would be result in the same behaviour but that isn't the case because the supplement uses the PtrHash as the key. Perhaps the hashtable shouldn't be using the ptr hash and just use a string hash?
Owner: jbroman@chromium.org Status: Started (was: Untriaged)
We could, but it'd be more expensive. Looking more closely, we could also ensure that you provide the type you're looking for and fetch T::kSupplementName, which we can guarantee is the same every time you access it. Trying that out locally.
(assigning to me because I've now been nerdsniped into trying this)
OK, changed this so that callers can no longer just supply a const char* of their own creation, and have to actually provide a type T that has T::kSupplementName. This should make this issue easier to avoid in the future.
Comment 1 by dtapu...@chromium.org
, Feb 8 2018