Possible @property compromise

[Steven Schveighoffer]

On Tue, 29 Jan 2013 23:57:14 -0500, Jesse Phillips  
<Jessekphillips+d at gmail.com> wrote:

> 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.

You are welcome to it!  I don't know if there is a thread on this  
newsgroup about properties that hasn't been hijacked.

I should explain that my reasoning behind this is:

1. Walter wants to get rid of @property
2. Dispite 4 years of assuming @property will be implemented, the old  
D1-style crap is still in place.
3. I've been using Objective C for the last 10 months, which implements a  
similar scheme to properties.

The compromise is: OK, you want to ditch @property?  I can live with that  
as long as we have some way to designate properties.  How about this?

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

The answer is no, but only because what we asked for was never  
implemented.  What was ORIGINALLY designed with @property (enforcement of  
parentheses on functions, enforcement against parentheses on properties)  
is what we wanted.

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

This is unavoidable.  It's like saying I feel some functions are  
incorrectly named.  @property has nothing to do with it.  There is no  
"right" answer to whether something should be a @property or not, just  
like there is no "right" name for a function.

> 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).

Yes, if the choice is between having the previous implementation (D1) and  
optional parentheses with a way to designate properties, I'll choose the  
latter.

> 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.

If you want to replace @property, we need a replacement.  @property still  
serves a purpose, even in it's currently crippled form.

> 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.

Fine, but leave @property in until you have completed the replacement  
feature.

> 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.

Ah, your subtle bias shines through ;)

The real fact of the matter is, if D never had the "hack" properties it  
did, I actually wouldn't care.  Calling functions instead of setting or  
getting properties is not that horrible.  But writeln = "hi" is horrible.

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

In general, the idea is to implement fields without having to create  
storage for them.  It will never perform as well as a field.

>
> ---------------------
>
> 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)

In other words, go back to D1 properties.  No thanks.

-Steve