Untested return values.

[Kristian]

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).

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.

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.

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'.