Untested return values.

[Lionello Lunesu]

Kristian wrote:
> On Thu, 05 Oct 2006 12:26:11 +0300, Lionello Lunesu 
> <lio at lunesu.remove.com> wrote:
> 
>> Andrei Khropov wrote:
>>> Walter Bright wrote:
>>>
>>>> I tried this back in the '80s. It's one of those things that sure 
>>>> sounds like
>>>> a good idea. The problem is, there are just too many cases where the 
>>>> return
>>>> value is legitimately ignored (like printf's), so you wind up 
>>>> filling your
>>>> code with chaff like:
>>>>
>>>>     cast(void) printf( ... );
>>>>
>>>> After a few dozen of those, it starts looking like a bad idea <g>.
>>>  Well, it depends on a particular syntax. In Nemerle for example it's 
>>> just  " _ = SomeFunc();"
>>>
>>
>> That's true! How about: "void = printf()", similar to the void 
>> initializer "int[] x = void;"
>>
>> L.
> 
> Well, I ignore return values of functions a lot.
> 
> For example, 'eraseFile()' returns true if a file was deleted or false 
> on failure. Usually I don't care what the return value is: if the file 
> couldn't be deleted, too bad, there is not much that I can do about it 
> (except possibly notify the user by opening a message box, but that's 
> not always wanted).

If you don't care whether the file got deleted, why do you delete it in 
the first place? OK, I know very well what you're trying to say and I do 
it myself all the time, but I'll also admit that it's sloppy programming.

Furthermore, 'the D way' is to throw an exception, not to return some 
value that is or is not tested.

By the way, do you often use

try { /* some code*/ } catch (Object o) {/* no code*/}

too? They should, since the same reasoning applies to function throwing 
an exception.


> The return value of such functions is a 'side effect', not the main 
> thing. Lets say that these functions belong to a group A. There are also 
> functions whose 'main thing' is their return value. There may or may not 
> be some 'side effects' when they are called. These functions belong to a 
> group B.

eraseFile returning 'false' is not a side-effect, it is the main thing 
not being done. A side effect would be printf returning the number of 
characters written.

> Clearly you wouldn't want to do any extra work when calling functions of 
> the group A. Or have warning/error messages with them. However, with the 
> group B that would be ok.

Granted, so perhaps it could be a warning message after all. Definately 
not an error, we've established that.

> One solution could be to tell the compiler that a function belongs to 
> the group B. For example:
> 
> pure double sqrt(double val);
> 
> void func() {
>     double x;
> 
>     sqrt(2.0);      //error
>     x = sqrt(2.0);  //ok
> }
> 
> Notice a new keyword 'pure'.

I like that. It's actually enabling that specific warning/error message 
on a per function basis. Functions returning handles to resources or 
fatal return values (mostly C libraries probably) could be tagged with 
this identifier and the compiler will then make sure the return value is 
actually used...

This is like a contract, in a way, for the caller of the function (as 
opposed to contact for the implementor.)

L.