On Thursday, 31 January 2013 at 01:26:19 UTC, Steven
Schveighoffer wrote:
On Tue, 29 Jan 2013 23:57:14 -0500, Jesse Phillips
<[email protected]> 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-@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.
