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". >:(

Reply via email to