[0xfaded]

I'm aware of this, however there is a pretty serious downside: function decorators (currying, whatever you want to call it) become difficult if type information is encoded in the function signature. For example, I mark handlers for logged in users by:

  handle(..., User(F))

The prototype of F and User might be

  func F(w http.ResponseWriter, r *http.Request, s *Session, i interface{})
  func User(...type of F...) func (http.ResponeWriter, r *http.Request, i interface{})

User() would do some preprocessing on the request and produce a Session for F. The problem is that User accepts ...type of F...; although it could accept an interface (of a function) but doing everything by reflection becomes cumbersome.

This is one of the things I don't like about go but really you need a type system like haskell's to achieve what I want here.

[groks]

You could create a dummy interface which all your DoParams-like types could implement:

    type Params interface { IsParams() }

Also, you can get away with passing a nil pointer for reflection rather than allocating a nil struct:

    fmt.Printf("nil pointer to DoParams: %T", (*DoParams)(nil))
    fmt.Printf("pointer to nil DoParams: %T", &DoParams{})

(Which isn't going to be a source of gc pressure in this instance, but still...)