Understandable, I knew this might get neg'd. I get that you don't like the non-const-ness of the `char *` in objc_method_description. Out of curiosity, which of the following are also true:

a) don't like struct's/typedef's inside functions, this way lies madness, non-euclidean geometry, Cthulhu, etc.
b) don't like putting system struct behind our own typedef.

### Completely gratuitous random thoughts without a better home

I was thinking it might be better if this function returned an... `ext_methodDescription` rather than an `NSMethodSignature`. In the case you needed the actual type encoding string, thus avoiding the whole (inexcusable of Apple, problematic-ish) need to reconstruct the full signature encoding via `-[NSMethodSignature typeEncoding]. You could wrap *that* function with another convenience function to return a `NSMethodSignature`. Needless complexity?

Because I'm realizing SELs are kind of a fail in general, I was also thinking what a pity it is that we don't have the entire `objc_method_description` all the time (which is kind of the motivation for this function). I'm wondering if the `Protocol` runtime functions -- which return the method description -- came later, after this realization was made Apple internal. (Thus interpreting the runtime so that the Apple team must think just like me; a nice trick.)