I had expected that the following code would crash:
It it intended?

----
import std.stdio;

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

void main()
{
	Foo.test1();
	/// Foo.test2(); crash as expected
	
	Foo f;
	f.test1(); /// works o.O - should crash?
	/// f.test2(); also crash - null pointer
}
----

You are invoking a function effectively stored statically in a class namespace. So you never actually dereference the null reference. You're just calling a function that doesn't really have anything to do with the reference. I prefer to tell it like it is and call the static method with the class name, so in this case that would be Foo.test1.

On 2013-06-20 21:17, w0rp wrote:
> You are invoking a function effectively stored statically in a class
> namespace. So you never actually dereference the null reference. You're
> just calling a function that doesn't really have anything to do with the
> reference. I prefer to tell it like it is and call the static method
> with the class name, so in this case that would be Foo.test1.

Yeah. It's possible to call any non-virtual method without dereferencing a null reference.

-- 
/Jacob Carlborg

Yes that's obvious. My question is: is that intended? IMO this could cause bugs.

On Thursday, June 20, 2013 21:38:57 Namespace wrote:
> Yes that's obvious. My question is: is that intended? IMO this could cause bugs.

It's a natural result of how the implementation works. Checking for null would just be extra overhead (Walter won't even do that for virtual functions which _will_ blow up when you call them on null references). And you'll get a segfault as soon as you actually use a member variable or virtual function with a null reference within a non-virtual function. So, I don't see why it would be a problem other than the fact that it's potentially confusing to people when they see a null this reference, since most people don't think that's possible.

And there's _definitely_ no point in checking if you're calling a static function. The only possible bug that you have there is if thought that you were calling a member function rather than a static function and that caused you to misunderstand what the code was doing and potentially write buggy stuff around it - but that's a problem caused by the fact that static functions can be called via an instance, and fixing that would mean making it illegal to call static functions on instances (which I would love to have happen but don't expect to ever happen).

- Jonathan M Davis

> but that's a problem caused by the fact that static functions can
> be called via an instance, and fixing that would mean making it illegal to call
> static functions on instances (which I would love to have happen but don't
> expect to ever happen).
>
> - Jonathan M Davis

What was the reason for this terrible design decision?

On Sat, Jun 22, 2013 at 06:34:25PM +0200, Namespace wrote:
> >but that's a problem caused by the fact that static functions can be called via an instance, and fixing that would mean making it illegal to call static functions on instances (which I would love to have happen but don't expect to ever happen).
> >
> >- Jonathan M Davis
> 
> What was the reason for this terrible design decision?

I've asked about that, but never got a real answer. I'm still hoping people would change their mind and reverse this bad decision. Conflating static members with non-static members is just a really bad idea.


T

-- 
"640K ought to be enough" -- Bill G., 1984. "The Internet is not a primary goal for PC usage" -- Bill G., 1995. "Linux has no impact on Microsoft's strategy" -- Bill G., 1999.

On Saturday, 22 June 2013 at 16:44:36 UTC, H. S. Teoh wrote:
> On Sat, Jun 22, 2013 at 06:34:25PM +0200, Namespace wrote:
>> >but that's a problem caused by the fact that static functions can be
>> >called via an instance, and fixing that would mean making it illegal
>> >to call static functions on instances (which I would love to have
>> >happen but don't expect to ever happen).
>> >
>> >- Jonathan M Davis
>> 
>> What was the reason for this terrible design decision?
>
> I've asked about that, but never got a real answer. I'm still hoping
> people would change their mind and reverse this bad decision. Conflating
> static members with non-static members is just a really bad idea.

I don't see what's so terrible about it: If A can do it, I don't see what an instance of a couldn't? I find that it is in line with what ufcs does: It streamlines the calling convention. This is particularly relevent to the fact that D has a lot of emphasis on "auto" type, which means that more often than not, it is easy to manipulate the instance, but more laborious to get the type.

EG: auto myObject = foo!"mode".getObject();
auto copy = myObject[0].bar.CreateInstance();

There! I wouldn't want to have to insert a typeof in there. My bar member is perfectly capable of creating and instance, so I don't see why I'd have to explicitly request this from the typeof.

... unless typeof could be used ufcs style, as a property, just like stringof et al. ... *THEN* we'd be talking.

I *HATE* writing "typeof(a).stringof" or whatever when everything screams at me to write "a.typeof.stringof". >:(

On 2013-06-22 19:11, monarch_dodra wrote:

> I don't see what's so terrible about it: If A can do it, I don't see
> what an instance of a couldn't?

The problem is that you cannot overload on "static". That is, have a two methods with the same name, one being declared "static". Usually it's possible to find a different name for one of the methods to avoid overloading. That's not always the case though, for example, opDispatch.

-- 
/Jacob Carlborg

On 06/22/2013 10:20 PM, Jacob Carlborg wrote:
> On 2013-06-22 19:11, monarch_dodra wrote:
>
>> I don't see what's so terrible about it: If A can do it, I don't see
>> what an instance of a couldn't?
>
> The problem is that you cannot overload on "static". That is, have a two
> methods with the same name, one being declared "static". Usually it's
> possible to find a different name for one of the methods to avoid
> overloading. That's not always the case though, for example, opDispatch.
>

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