Possible @property compromise

[Jesse Phillips]

On Thursday, 31 January 2013 at 01:26:19 UTC, Steven 
Schveighoffer wrote:
> 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.

Thank you.

> I should explain that my reasoning behind this is:
>
> 1. Walter wants to get rid of @property

I can't really speak to what Walter wants, but I think there is 
more to it than removing a keyword.

> 2. Dispite 4 years of assuming @property will be implemented, 
> the old D1-style crap is still in place.

Yep, I thought its introduction meant things were going to break, 
and also that other things would work.

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

I don't think that is a compromise as i don't believe it is 
@property that is slated for removal, it is designating something 
a property.

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

Yep, totally thought that was coming. I'd still be ok with it, 
but I'm still partial to not having it enforced, would rather see 
field -> property a seamless transition.

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

Yes, but I was thinking more on the degree of wrongness that is 
currently acceptable. Something to think on for what my proposal 
would be. But again, I don't care about the appearance, only 
behavior.

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

Walter's suggestion isn't (D1) implementation it address some 
concerns with the existing behavior, but doesn't give you a way 
to declare properties.

I think his suggestions need implemented regardless of what we do 
with @property. I think Walter just felt this would appease the 
pro-property.

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

What purpose is that? Isn't it a no-op by default, and barely 
enforce () with -property?

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

I'm not sure if we are going to have a complete replacement, but 
your right, we can leave it in until such a choice is finalized, 
but let us get rid of -property.

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

Yep, introducing properties would have been easy, because no one 
would have fallen for the joys of optional parens.

writeln = "hi" would not compile with Walters suggested changes.

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

I know, but you can't trust when reading code that is what 
happens. And having that convention was being argued for, I like 
Walter's position of having the compiler make guarantees and not 
conventions (I'm sure I've got some exception I'd want but can't 
think of one).

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

Again, it wouldn't be D1, and we aren't going back because that 
is what we currently have. We need to fix it.

>
> -Steve

Thanks for the feedback.