On 2013-06-22 23:51, Timon Gehr wrote:

> If that is the only problem then the solution is to allow overloading on
> static, which is easy to do.

You still need to call the static method on the class/struct if there's an ambiguity.

-- 
/Jacob Carlborg

> I don't see what's so terrible about it

It's bug prone.

class Foo {
public:
	static void test1() { }
	void test2() { }
}

Foo f;
f.test1(); /// Oh nice, that works, f is not null.
f.test2(); /// WTF? f is null?

Also I don't know why I should call static methods from an instance. What's the purpose?

On Sunday, June 23, 2013 11:30:11 Jacob Carlborg wrote:
> On 2013-06-22 23:51, Timon Gehr wrote:
> > If that is the only problem then the solution is to allow overloading on static, which is easy to do.
> 
> You still need to call the static method on the class/struct if there's an ambiguity.

I would have thought that that was obvious, and I fail to see why that would be a problem. The only risk I see in allowing static and non-static functions to be overloaded, is that if you have static function being called with an instance, and you add a non-static overload, then the code would silently change to call the non-static function. But we have that exact same problem with UFCS and member functions as it is, and that wouldn't break any existing code (since you can't overload on static right now). It would just be a future risk of breaking code.

- Jonathan M Davis

On Sunday, June 23, 2013 12:02:42 Namespace wrote:
> > I don't see what's so terrible about it
> 
> It's bug prone.
> 
> class Foo {
> public:
> 	static void test1() { }
> 	void test2() { }
> }
> 
> Foo f;
> f.test1(); /// Oh nice, that works, f is not null.
> f.test2(); /// WTF? f is null?

I fail to see what's bug-prone about that. It's confusing, but it's not causing any bugs.

> Also I don't know why I should call static methods from an instance. What's the purpose?

It's stupid and pointless as far as I can tell, but I believe that C++, Java, C#, and D all do it, so as stupid as it is, it's a common stupidity. I certainly wish that we could change it, but I wouldn't expect Walter to agree to the change, since it would break at least some existing code, and I suspect that he doesn't consider the fact that you can call static functions on instances to be a problem. That's not the sort of thing that he generally seems to think is an issue. It's almost always stuff that causes actual bugs that he agrees to change and not things that are aesthetically displeasing or which could theoretically cause bugs.

- Jonathan M Davis

On Sunday, 23 June 2013 at 10:09:39 UTC, Jonathan M Davis wrote:
> On Sunday, June 23, 2013 12:02:42 Namespace wrote:
>> > I don't see what's so terrible about it
>> 
>> It's bug prone.
>> 
>> class Foo {
>> public:
>> 	static void test1() { }
>> 	void test2() { }
>> }
>> 
>> Foo f;
>> f.test1(); /// Oh nice, that works, f is not null.
>> f.test2(); /// WTF? f is null?
>
> I fail to see what's bug-prone about that. It's confusing, but it's not
> causing any bugs.
>
>> Also I don't know why I should call static methods from an
>> instance. What's the purpose?
>
> It's stupid and pointless as far as I can tell, but I believe that C++, Java,
> C#, and D all do it, so as stupid as it is, it's a common stupidity. I
> certainly wish that we could change it, but I wouldn't expect Walter to agree
> to the change, since it would break at least some existing code, and I suspect
> that he doesn't consider the fact that you can call static functions on
> instances to be a problem. That's not the sort of thing that he generally
> seems to think is an issue. It's almost always stuff that causes actual bugs
> that he agrees to change and not things that are aesthetically displeasing or
> which could theoretically cause bugs.
>
> - Jonathan M Davis

C++ doesn't allow it. I don't know about the rest.

If anything, I find overloading static non static could make sense:

A.print(); //"I'm an A!"
a.print(); //"I'm an A called foo!"

With this in mind, it can mean that a struct can first define the static function, and in the future, add extra logic to handle information from a specific instance, yet without having to caller code.

On Sunday, June 23, 2013 12:48:15 monarch_dodra wrote:
> C++ doesn't allow it. I don't know about the rest.

Yes it does. I just tested it. This code compiles and runs just fine

#include <iostream>

using namespace std;

class C
{
public:
    static void foo()
    {
        cout << "I'm static!" << endl;
    }
};

int main()
{
    C c;
    c.foo();
    return 0;
}

And just like D, C++ won't allow you to overload on static (also just tested), so D's behavior in this regard appears to be identical to C++.

- Jonathan M Davis

On Sunday, 23 June 2013 at 10:59:06 UTC, Jonathan M Davis wrote:
> On Sunday, June 23, 2013 12:48:15 monarch_dodra wrote:
>> C++ doesn't allow it. I don't know about the rest.
>
> Yes it does.
>
> - Jonathan M Davis

Oh. Wow. That's news to me actually. I thought I new everything about C++ ^^

On 2013-06-23 12:04, Jonathan M Davis wrote:

> I would have thought that that was obvious, and I fail to see why that would
> be a problem. The only risk I see in allowing static and non-static functions
> to be overloaded, is that if you have static function being called with an
> instance, and you add a non-static overload, then the code would silently
> change to call the non-static function. But we have that exact same problem
> with UFCS and member functions as it is, and that wouldn't break any existing
> code (since you can't overload on static right now). It would just be a future
> risk of breaking code.

That's true, I didn't think of that.

-- 
/Jacob Carlborg

On Sunday, June 23, 2013 13:35:55 monarch_dodra wrote:
> On Sunday, 23 June 2013 at 10:59:06 UTC, Jonathan M Davis wrote:
> > On Sunday, June 23, 2013 12:48:15 monarch_dodra wrote:
> >> C++ doesn't allow it. I don't know about the rest.
> > 
> > Yes it does.
> > 
> > - Jonathan M Davis
> 
> Oh. Wow. That's news to me actually. I thought I new everything about C++ ^^

LOL. I know a lot about C++ and _try_ to know it all, but C++ is just way too complicated for that (at least for me). Even if I learn all of the stray esoteric stuff, I can't retain it all. There's just too much of it.

With D, I feel like I _might_ be able to do it. I definitely don't know everything that there is to know about D, and I don't always remember all of the little details that I learn (plus some of them change over time), but I do a much better job of remembering it. It doesn't have anywhere near as many dark corners to it, and so in spite of its complexity, it at least feels like it could all be understood and remembered by one person (unlike C++). So, _maybe_ someday I'll be able to claim that I know the D language through and through, but I'll definitely _never_ be able to claim that with C++.

- Jonathan M Davis

On Sun, 23 Jun 2013 06:09:19 -0400, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Sunday, June 23, 2013 12:02:42 Namespace wrote:

>> Also I don't know why I should call static methods from an
>> instance. What's the purpose?
>
> It's stupid and pointless as far as I can tell, but I believe that C++, Java,
> C#, and D all do it, so as stupid as it is, it's a common stupidity. I
> certainly wish that we could change it, but I wouldn't expect Walter to agree
> to the change, since it would break at least some existing code, and I suspect
> that he doesn't consider the fact that you can call static functions on
> instances to be a problem. That's not the sort of thing that he generally
> seems to think is an issue. It's almost always stuff that causes actual bugs
> that he agrees to change and not things that are aesthetically displeasing or
> which could theoretically cause bugs.

I actually had a bug caused by this.

But the reason is simply duck typing.

For example:

class InfiniteRange
{
  ...
  static bool empty() { return false; }
}

My suggestion to fix this has always been: only allow static calls on instance variables via opt-in.  e.g.:

class InfiniteRange
{
   static bool empty() { return false; }
   alias InfiniteRange.empty this.empty; // just an example
}

This allows all the benefit, but none of the bug-prone problems.

-Steve