On Thu, 24 Jan 2013 13:26:11 -0800, Jonathan M Davis <[email protected]>
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/
