🚀 go-pugleaf

John (MAX) Skaller writes:
> Similarly,
> 
>   f(int*);
>   f(const int*);
> 
> would not both be allowed. The argument in favour of this
> is that overloading is for two purposes:
> 
> A)     families of semantically equivalent operations on different types
>   e.g. sin(float), sin(complex)
> 
> B)  [omitted]
>              
> In case (A) overloading is desirable because the associated
> 'transparency' renders the program more readable and amenable
> to change of the types (float->complex). 
> 
> Addition of extra overloaded functions may cause re-binding,
> say sin(double) is added, but it doesnt really matter
> because this doesnt affect the overall semantics.

In the cases where I've seen overloading based on const, there is a very tight
semantic relationship between the overloaded functions, so tight
that they would be the same function except for a difference in
return type.  For example,
      int & access_the_count (class S&);
      const int & access_the_count (const class S&);
in which the overloaded function is providing access to a concrete
or abstract element of an object, and whether the element is const
or not depends on whether the object is const or not.
--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com