Reddit: why aren't people using D?

[Ary Borenszweig]

Steven Schveighoffer wrote:
> On Fri, 24 Jul 2009 14:10:59 -0400, Walter Bright 
> <newshound1 at digitalmars.com> wrote:
> 
>> Steven Schveighoffer wrote:
>>> I don't think properties should be necessarily pure anyways.  How do 
>>> you have a pure setter?  It's more of a convention that a property 
>>> getter should not change the state of the containing entity, a pretty 
>>> much non-enforcable convention.
>>
>> That's my problem with properties as a distinct syntax - they don't 
>> have distinct uses or behaviors.
> 
> If you delineate what can be called how, then you elminate syntax 
> ambiguities from occurring, and eliminate bizarro cases of syntax.  The 
> difficulty is that the "human meaning" of a property is different than 
> the human meaning of a function.  To the compiler, they're all 
> functions, so you as the compiler writer aren't seeing that they are 
> different.  I think we all agree that writefln = "hi"; makes absolutely 
> no sense to a person.  But it makes complete sense to the compiler, 
> because it has no idea what the word "writefln" means to a person.
> 
> It's the exact same reason + is not the concatenation operator.  
> Semantically, making + concatenate two strings together would be 
> completely unambiguous from adding two integers together because strings 
> do not define addition, and integers do not define concatenation.  From 
> your own documentation, someone seeing "10" + 3 might think that he 
> would get 13 or "103".  Even if the compiler defines what "should" 
> happen, and the rules are unambiguous, it looks incorrect to the user.
> 
> But having ~ be the concatenation operator makes it completely 
> unambiguous what the syntax means, regardless of what the types are.   
> So the compiler and the user are talking the same language, and the user 
> isn't freaked out by the "human meaning" of the syntax.
> 
> -Steve

Maybe what scares Walter is a whole new syntax for properties. If at 
least you could say which functions are properties and which are not, 
that would be a small change and it'll make it possible for other 
things. Something like:

int property foo(); // getter
int property foo(int value); // setter

So properties are marked with a modifier and that's it. The compiler 
could discard those modifiers or, much better, disallow doing things like:

bar = 3; // ERROR: bar is not a property
foo(); // ERROR: foo is a property and must be used as foo

Now we need someone to think which of the current keywords could be used 
instead of "property". :-P