Agreed. As I indicated later, throwing away useful information wasn't my
intent -- having a tight, well-defined contract was. T serves that purpose,
but other values may also serve it and add utility at the same time.
The WORST case, in my mind, is to return something useful, but leave the
contrac
Just to clarify my earlier stance: I agree -- if there's something
well-defined and more useful than T to return, return that. It's the
'null/non-null' contracts that are problematic.
The extra wiggle-room here offers no utility at all. It does allow for one
branch of an implementation to avoid a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
I would not like such a rule in a style guide, for fear of religious
followers. My view is: yes, tighten the contract, but no, it needs
not (but may) specify exactly t. If something useful can be returned,
why throw it away?
Best wishes
Svante
