> I don't think there should be separate rules for > events vs. other functions; events are special only in how and where > they are invoked, but in every other respect are currently like any > other method. Yet we don't want to require returns for events, since > that would cause quite a bit of grief.
Do events need a special rule? What if any function that had code in it could be forced to have a return value? I take the points about compiler warnings -- if you want to call it an analysis tool and make me pull down a menu item to run it, fine. I'm not sure how that changes the situation with third-party code; if it's dirty, you'll ignore the flaw report and get into the habit of not running it. I guess I don't care if most programmers don't use this option, just like I don't care if they choose poor naming conventions or fail to check for nil object references -- the compiler can save me significant debugging time by making this simple check, preventing an error on my part, so I should be able to ask it to. lj _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
