Possible @property compromise

[Jesse Phillips]

Sorry I have to oppose this. It is in no way a compromise as it 
is completely different from everything suggested. I'm going to 
take this opportunity to highjack your thread.

Can an pro- at property members claim that the current behavior is 
what you want? I believe this answer is no.

It seems at least some members for @property feel that currently 
functions are being annotated with @property that shouldn't be.

It also seems those for @property aren't fighting optional parens 
as much? Can we discuss fixing the issues we have with this. I 
think a good change is to require parens if returning a callable 
(opposite of Walters suggestion).

--------------------

If I have my above claims mostly correct, then I'd say @property 
needs to be put back in the drawing board and re-implemented.

I'd be for removing it from the language and if we decide on what 
in needs to enforce and should be part of the language, then its 
implementation is completed in a feature branch and remains out 
of the language until it meets the needed enforcement and 
behavior.

Granted I'm not concerned if it doesn't ever come back. I believe 
it has a legitimate role in allowing a change from field to 
function without harming usage that can not be achieved without 
an annotation. However it seems we can't achieve this with the 
combination of features D employs.

I don't agree with the argument that properties provide a 
convince to identify low overhead access. While I'm not 
experienced in this area, profile code should indicate where 
performance is poor, it would be bad to assume "that looks like a 
field, so it must not be where the performance is bad."

---------------------

So let us decide to keep optional (), fix what we can there.

Define what is desired of properties, but for now get rid of what 
we currently know as @property. Then with a complete proposal, we 
can say it must meet these goals or it won't exist. Since 
optional () remain, introducing @property again will not break 
code and we will only deal with broken code now (and there would 
be some just to fix the current behavior and its disconnect with 
-property)