Possible @property compromise

[Steven Schveighoffer]

On Thu, 31 Jan 2013 19:01:02 -0500, Jesse Phillips  
<Jessekphillips+D at gmail.com> wrote:

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

I meant the @property design, including the keyword.  Basically whatever  
@property was supposed to stand for.

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

I don't think that's the case.  D1 has a designation of what is a property  
-- if it has no arguments it is a getter, if it has a single argument it  
is a setter.

The extra rules Walter is proposing are a half-baked design that covers  
some cases.  But the rules are controlling the behavior based on  
superficial observations instead of allowing an author to express specific  
intents.  It sounds like something Congress would come up with...

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

First, it's not seamless without a keyword or special syntax (remember the  
delegate problem).  Second, that's not a mutually exclusive choice.  If  
you enforce property syntax, then it's still seamless (and even more so  
since you actually *CAN* implement what is desired).

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

Then why ever have properties at all?  Functions work just fine.

>>> 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 you are misunderstanding his proposal.  Under his proposal, two  
completely unrelated and unconnected functions could combine together to  
allow a setter that is completely unintended.  Instead of specifying  
intent, we have to jump through the compiler hoops to avoid accidental  
intent.  This is not a solution, it's actually worse than D1 style  
properties.  You'll have code that can call a 'setter' on an object or  
struct with no 'getter' and you'll have no idea why.

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

I certainly hope none of his suggestions are implemented, they will only  
confuse the situation.

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

The purpose is to specify intent "I declare this is a property, use it  
that way".  It's the whole point of having a property syntax.  It's just  
not enforced by the compiler.

The compiler has numerous bugs on it, that doesn't mean the features  
should be ditched, it means we have to correctly implement those  
features.  array.dup allows implicit casting away from immutable (at least  
it did, not sure if that was fixed).  Does that mean we should get rid of  
dup?

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

That doesn't hurt anything, that switch is an experimental feature, and  
once we have the blessed property syntax, we likely will need that  
experimental feature to obey the new syntax.

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

I see only minor issue with optional parens.  It's the setters that are  
the most disruptive.

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

No, but other abuses would.

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

The compiler cannot make performance guarantees of any kind really.  That  
is up to convention.  Properties do provide a *mechanism* to create a  
convention.  What the convention is remains the will of the author.

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

OK, I stand corrected, if it is a choice between D1 properties and  
Walter's new rules, I'll choose D1 properties.  At least I know what I get  
there.  But if we have *any* property syntax at all, I'd prefer that.   
Even the current design, while not implemented, has the PROMISE of having  
a fully functional property syntax.  I prefer the promise of something  
that is usable to something that is utterly useless, even if it's already  
implemented.

-Steve