Reddit: why aren't people using D?

[Daniel Keep]

Walter Bright wrote:
> Michiel Helvensteijn wrote:
>> That's just a few reasons right there. D's properties lack elegance
>> and they
>> lack potential.

> Let's start with:
> 
> 1. What is a property?

A piece of state referred to by some name; state which is usually part
of some object.  Semantically the same as a field, except it may be more
complex then just an address in memory.

I'm going to fudge your next question a little...  We've already
established that pure functions won't cut it since they prevent you from
doing lazy loads, or anything involving mutation (like tracking access
counts).  So let's pretend the question was:

> 2. How is that different from, say, a function?

Which has a more interesting answer.  :)

In terms of machine code, nothing.  This isn't a question about
functionality, in the end, it's a question of intent.

To reiterate: something like Qt depends pretty heavily on properties
being distinct from functions.  For example:

T foo();
T foo(T);

Is foo a property or a function?  It's impossible to tell.  It could be
a function with two overloads, one of which requires an argument, or it
could be a getter/setter pair.

This causes a few problems.  The first of which, and the one that I
think is the most important, is it cripples IDEs and other graphical
tools.  Another example: I'm in the planning stages for a graphical
editor that snaps together components.  I'd love to be able to just
introspect an object at runtime and grab all the properties, but I
can't.  I cannot determine, for certain, which methods are properties
and which are REALLY methods, so I'll probably end up doing something
like this:

class Blah : Component
{
    mixin(properties("a", "b", "c"));
}

To identify them.  Of course, this isn't much use for a general IDE,
unless this sort of thing becomes a standard in the language, and even
then it's pretty hideous.

Another problem is the issue with leaving off parens.  The canonical
example being:

struct Foo
{
  int delegate() bar();
}

You have to put in *two* sets of parens to call the result from bar, not
one as might be assumed.

There's also the argument for debuggers being able to automatically
display properties; I think this one is fairly borderline since if I was
writing a debugger, it would only *automatically* display the result of
pure functions, property or not.

Finally, there's a speculative argument in that the current arrangement
limits properties to having a getter and/or a setter.  Andrei made a
comment a while back about needing three primitives for them to work
properly; in the current system.

---

So basically, the issues are not *really* technical; they all boil down
to ambiguity in terms of interpretation, or clumsy corner cases.

To speak of the technical implementation of properties, my comments on
DIP4 basically recommends to implement "new style" properties almost
EXACTLY THE SAME as current ones; the difference is that "new style"
properties have slightly more information available about them.


I hope all that helps, although I suspect I'm just rambling at this
point.  :)