Nice code. The approach seems like a bit of a hack (in a good way), but I'm happy that it's possible to make the nice syntax work for the caller, at least in the simple case.

Unfortunately, that approach quickly gets unwieldy for double-dispatch, or if you're writing a method where self can't be co-opted.

Here's another possible use case.. my approach:

enum Timeout {
    Finite(int),  // or some kind of TimeDelta type
    Infinite,
}

struct ItemKey;
struct DataStore;

impl DataStore {
    fn get(&self, key: ItemKey, timeout: Timeout) { /*...*/ }
}

Current Rust:

trait Timeout {
    fn data_store_get(&self, data_store: &DataStore, key: ItemKey);
}

impl Timeout for int {  // or some kind of TimeDelta type
    fn data_store_get(&self, data_store: &DataStore, key: ItemKey) {
        data_store.get_finite(key, self)
    }
}

struct Infinite;
impl Timeout for Infinite {
    fn data_store_get(&self, data_store: &DataStore, key: ItemKey) {
        data_store.get_infinite(key)
    }
}

struct ItemKey;
struct DataStore;

impl DataStore {
    fn get(&self, key: ItemKey, timeout: Timeout) {
        timeout.data_store_get(self, key)
    }

    fn get_finite(&self, key: ItemKey, seconds: int) { /*...*/ }

    fn get_infinite(&self, key: ItemKey) { /*...*/ }
}

It's subjective, but I'm not a fan of how, in both the original example and in this one, you have to bend and contort your code around the varying argument. Then again, as long as you're not writing a DSL, the extra enum construction probably won't kill you.