> Basically, the issue is that developers have a two-fold expectation of > a subprogram pointer, namely, to support indirect invocation and also > subprogram identification. Right. It's quite unreasonable to expect that something designed for the former will just happen to also support the latter, and the developers shouldn'a done it. In addition to the generic wrapper situation, think of a system where a subprogram can have different addresses during the course of execution. A system with multiple loosely coupled CPUs each of which may have its own copy of parts of the program in its own memory, for instance. The only language change that seems reasonable would be to eliminate the "=" operator for subprogram access types. That probably wouldn't be very helpful for your situation. You could educate your developers about using dispatching instead of callbacks. That would be a good long term approach. In the short term, how about a memo like: To: Software Developers Subject: registering callbacks Many systems currently un-register a callback by means of a second call like "unregister(routine'access);". This is slow, since it involves a search by the registrar, and it's not safe, since different "routine'access" can in fact return different values, for instance in generics or multi-processor systems. It's both faster and safer to [description of your preferred variant of (c), the ID/laundry tag system].