Overloading static methods

[Steven Schveighoffer]

On Tue, 30 Aug 2011 11:38:54 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 8/30/11 7:34 AM, Steven Schveighoffer wrote:
>> On Tue, 30 Aug 2011 07:53:15 -0400, Steven Schveighoffer
>> <schveiguy at yahoo.com> wrote:
>>
>>> On Mon, 29 Aug 2011 10:59:22 -0400, Daniel Murphy
>>> <yebblies at nospamgmail.com> wrote:
>>>
>>>> "Steven Schveighoffer" <schveiguy at yahoo.com> wrote in message
>>>> news:op.v0zckubyeav7ka at localhost.localdomain...
>>>>>
>>>>> My opinion is that static methods should *not* be callable from an
>>>>> instance, you should need typeof(instance).staticMethod. The current
>>>>> allowance is misleading.
>>>>>
>>>>> This should solve some of the issues, but of course, you'd need to
>>>>> allow
>>>>> overloading of the method name in static and non-static forms.
>>>>>
>>>>> -Steve
>>>>
>>>> I like this idea. Is there a bugzilla entry for it?
>>>
>>> I'll add it, if it's not already there.
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=6579
>>
>> -Steve
>
> I'll note that calls of static methods for instances has been a boon to  
> generic programming in C++. People could call a method and it was up to  
> the implementation whether it was static or not.

Yes, you are right.  But there is an ugly flip side to that coin.

The issue is, when someone designs a static method to be called on an  
*instance*, it makes sense.  But when someone designs a static method to  
be called on the *type* (which is predominantly how I write them), it  
often does not make any sense to call it on the instance.  Yet, the  
compiler still compiles.

An example I gave in the bug report just now is File.  Imagine you have a  
File struct, and want to have an open method:

struct File
{
    static File open(string fname);
}

However, now this is valid code:

File f;
f.open(fname);  // does not do what you think it does...

I agree there are ways to design around this, but the fact that the  
intentions of the designer are not upheld (and cannot be) by the compiler  
is troubling to me.  I *named* the function expecting it to be called a  
certain way, yet confusion abounds when called some way I didn't intend or  
anticipate.  One seldom thinks of the instance-calling-static mechanism  
when designing a static method that is meant to be called with the type.

> We don't have as big a problem in D due to introspection. I fear,  
> however, that we'll need to add static if (...) obj.method(); else  
> typeof(obj).method();
>
> I don't see an improvement.

In terms of generic programming, you have a good point.  I don't see a  
good way around this without altering syntax.

Perhaps we could do something like this (a la recently added @disable  
this):

struct File
{
    static File open(string fname);

    @disable open; // disable calling from an instance
}

Yuck...  nevermind :)

-Steve