Understanding ~Copyable lifetime for scope-based instrumentation (Probes)

[jamieQ (Jamie)]

@FlorianPircher

As far as I have observed the discussion around ~Copyable, this is explicitly not something that Swift offers.

i believe when it comes to ~Copyable structs at least this is incorrect. non-copyable structs have 'lexical lifetimes' which are well defined. this thread may be of interest, and i'm basing this assertion primarily on what Andy said here:

@Andrew_Trick

Swift's ~Copyable struct deinits are different. They are strictly ordered. They run when the variable is consumed or goes out of scope. If you want to rely on the order of deinitialization, use ~Copyable.

---

@Orion98mc

However, I’ve noticed that the Swift compiler is very efficient and destroys my probe as soon as it's no longer "used" in the code, which is often way before the end of the function.

i believe this is an implementation artifact of the particular pattern you're using where the probe is never given a name. if you name the variable you should see the behavior you expect where its deinit runs at the end of scope:

func atExit() {
  let p = ScopeProbe("...")
  // do stuff ...
  // deinit runs here
}

awkwardly, if you never use the variable, this will generate an unused variable warning, so if you want to eliminate that you'll also need a use.

@Orion98mc

However, even with a named variable (e.g., let probe = ...), if the variable isn't accessed later, the Lexical Lifetime optimization seems to reclaim it eagerly.

IIUC this would be a bug, since the purpose of lexical lifetimes is to anchor lifetimes to the corresponding lexical scope. do you have an example that reproduces this behavior?

---

in terms of more ergonomic options – the class-based approach with defer is decent (though perhaps less performant). you may want to look into a macro (and maybe a function body macro).