I see two oddities in the proposed unmask_secret_to. First, you have to use the buffer both as the invocant as well as an argument which is odd. Second, If you had two secrets that interface would be confusing, does it unmask the other secret or not?

my $other_secret = Crypt::SecretBuffer->new("Foo");
$password->unmask_secret_to(\&do_something, $user, $password, $other_s
+ecret);
[download]

Making unmask_secrets_to a plain exportable sub, not a method would address these issues (at least makes it clear what will happen in the second case). You could also implement an unmask_to (apply) method which would allow fine-grained access for multiple secret cases (or some people will just prefer that approach). So, "why not both"?

I do not like #3, it is too easy to do accidentally and entirely un-greppable.

On bikeshedding, for something that unmasks a secret, a generic name like "apply" isn't a good match. I'd suggest something greppable like unmask_to (which would be consistent with the unmask_secrets_to sub), or call_with_unmasked, or just unmask,

my $other_secret = Crypt::SecretBuffer->new("Foo");
$password->unmask_to(sub($pass) { do_something($user, $pass, $other_se
+cret) });
[download]

Update: Supporting SecretBuffers in another library could, I guess, look a bit like this (in the typical case of just wanting to unwrap any secrets passed in):

use 5.036;

*unmask_secrets_to =
    eval { require Crypt::SecretBuffer; \&Crypt::SecretBuffer::unmask_
+secrets_to }
    || sub($cb, @args) { &$cb(@args) }
;

sub private_fn {
    say "@_";
}

sub my_api_function($user, $password, $secret) {
    unmask_secrets_to(\&private_fn, $user, $password, $secret);
}
[download]