@property - take it behind the woodshed and shoot it?

[Adam Wilson]

On Thu, 24 Jan 2013 13:26:11 -0800, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> On Thursday, January 24, 2013 22:06:02 mist wrote:
>> On Thursday, 24 January 2013 at 21:00:32 UTC, Andrei Alexandrescu
>>
>> wrote:
>> > On 1/24/13 3:58 PM, mist wrote:
>> >> Really, all this backwards-compatibility talk is a crap.
>> >
>> > There's just a lot of evidence that suggests the contrary.
>> > Clearly we don't want or like to be conservative, but
>> > apparently we need to.
>> >
>> > Andrei
>>
>> Do you read and answer only to the first sentence? Can you
>> honestly say "D design is rock solid and correct, we will never
>> be required to make any backwards-incompatible change"?
>>
>> If you check those evidences, it was never breaking code alone.
>> It was breaking code AND lack of any sane process that allows to
>> stick with acceptable release version for longer time. And I
>> suggest to fix the right thing, not freeze specs and hope all
>> problems will fade themselves.
>
> The problem is that we have competing goals that we have to deal with
>
> 1. Fix any problems in the language so that its design is solid.
>
> 2. Avoid breaking people's code.
>
> If we don't do enough of #1, then D will have serious problems, but if  
> we do
> too much of it, then we'll serious problems because with #2. Even if we  
> end up
> with the perfect language when we're done, it doesn't matter much if no  
> one's
> using it, and if we are forever breaking people's code, then they're not  
> going
> to stick around. The trick is deciding when and how we need to and can  
> get
> away with breaking code. And the longer it takes to solve major design  
> flaws in
> the language which require breaking code, the more code we'll break when  
> we do
> make the changes, and the more problems will have, which is one reason  
> why
> it's so frustrating that it often takes quite a while to properly sort  
> this
> sort of thing out.
>
> - Jonathan M Davis

I don't think we can fix @property (or remove it) without breaking code.  
So I would plead with the community to accept that. This is a very  
important problem to fix.

Obviously deciding how to proceed is going to be difficult but I don't  
think that we have copious amounts of time for the community to slug it  
out either. You either break properties or optional parens, either way  
creates problems.

I would argue that removing @property creates more problems than removing  
optional parens. One is a highly delicate surgical operation on the parser  
to handle all the new ambiguities, more documentation to explain, and more  
chances to the user to D the wrong (but still acceptable) thing, and  
requires large amounts code refactoring. The other is a simple  
find/replace in user code, with some simple changes to the parser.

I will always vote for the less bug-prone path. Remove Optional Parens.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/