You can mimic this in most languages: createFile(name, contents, /* temporary= */ true). Of course that doesn't guarantee that that's what that parameter is actually named, but you can write a lint for that (with quite a bit of effort).
I’ve found the odds of that happening approach certainty once you have more than one or two parameters. If you’re using a language without named arguments I usually treat adding a third parameter as a cue to reconsider using a more idiomatic interface, whether that’s something like classic Java OOP (.setTemporary(true)) or limiting that knowledge to one place by e.g. creating a subclass, struct, or a specialized function so you call createTemporaryFile() and know that ordering check only needs to be done in one place rather than by every caller.
For example, you could mean
createFile(name, contents, /* temporary= */ true, /* overwrite= */ true)
createFile(name, contents, /* overwrite= */ true, /* temporary= */ true)
Writing documentation that that merely copies existing code is terrible: it's either going to be wrong (because it's not automatically checked and will go sour in a refactoring, or it's right because it's so obvious that no one will guess wrong when looking at it.)