Steven Schveighoffer wrote:
On Fri, 24 Jul 2009 14:10:59 -0400, Walter Bright
<newshou...@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
