On Thursday, 24 January 2013 at 20:52:10 UTC, Walter Bright wrote:
> On 1/24/2013 5:42 AM, Jacob Carlborg wrote:
>> I agree with you but Walter is very afraid of breaking code.
>
> The history of what happens when D code breaks because of language changes is not a happy one.

<rage>Please. Go to http://wiki.dlang.org/Release_Process . Read it. Answer the question "Hm, does having well-defined release process with long-term support versions help with instability of breaking changes?". And if answer is "no" then you probably should have contributed your opinion there for a long time, because it _should_ to.</rage>

Really, all this backwards-compatibility talk is a crap. There is no way we can say current D design is final and solid and can be polished without any breaking changes. We should not argue about how bad breaking is. We should discus how to do those changes in the least harmful way.

On 1/24/13 3:45 PM, Nick Sabalausky wrote:
> On Thu, 24 Jan 2013 12:51:32 -0500
> Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org>  wrote:
> No, you merely came up with *some* specific cherry-picked examples that
> sparked *some* debate (with most of the disagreing coming from
> you).

I simply mentioned three reasons that came to mind.

Andrei

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

On Thursday, January 24, 2013 21:47:38 mist wrote:
> On Thursday, 24 January 2013 at 20:44:33 UTC, eles wrote:
> > On Thursday, 24 January 2013 at 20:26:50 UTC, mist wrote:
> >> On Thursday, 24 January 2013 at 20:20:42 UTC, Adam Wilson
> > 
> >> wrote:
> > I think the widest spread use case of a property is:
> > 
> > you start with a variable as memeber of a class, you write a lot
> > of assignment code, then you decide that you need to do some
> > more
> > extensive processing instead of simple assignment, and all that
> > without breaking existing code.
> > 
> > so, you transform the variable into a property.
> > 
> > of course, it could happen the other way around (converting a
> > function into a property/variable).
> 
> It is a wrong use case for a property. Necessity to change data assignment/access to call of function with side-effect is design error and should be fixed with programmers experience, not property hacks.

Being able to swap out a public variable with a function without having to change any code using it is arguably the primary reasons that property functions exist in the first place. Yes, making it so that the property function has a _side-effect_ is a bug, but replacing variables with property functions is not. A classic example of why it's useful is when you refactor a class such that a public variable becomes a calculated value such that it doesn't make sense to have a variable for it anymore. Instead of breaking all of the code that uses the variable by changing it a function, you change it to be a property function, and all of the code which used it continues to compile and work just fine.

D's properties need some work before that will really work properly (e.g. http://d.puremagic.com/issues/show_bug.cgi?id=8006 ), but it works just fine with property implementations in other languages (e.g. C#).

- Jonathan M Davis

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.

On Thu, 24 Jan 2013 13:00:35 -0800, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Thursday, January 24, 2013 21:47:38 mist wrote:
>> On Thursday, 24 January 2013 at 20:44:33 UTC, eles wrote:
>> > On Thursday, 24 January 2013 at 20:26:50 UTC, mist wrote:
>> >> On Thursday, 24 January 2013 at 20:20:42 UTC, Adam Wilson
>> >
>> >> wrote:
>> > I think the widest spread use case of a property is:
>> >
>> > you start with a variable as memeber of a class, you write a lot
>> > of assignment code, then you decide that you need to do some
>> > more
>> > extensive processing instead of simple assignment, and all that
>> > without breaking existing code.
>> >
>> > so, you transform the variable into a property.
>> >
>> > of course, it could happen the other way around (converting a
>> > function into a property/variable).
>>
>> It is a wrong use case for a property. Necessity to change data
>> assignment/access to call of function with side-effect is design
>> error and should be fixed with programmers experience, not
>> property hacks.
>
> Being able to swap out a public variable with a function without having to
> change any code using it is arguably the primary reasons that property
> functions exist in the first place. Yes, making it so that the property
> function has a _side-effect_ is a bug, but replacing variables with property
> functions is not. A classic example of why it's useful is when you refactor a
> class such that a public variable becomes a calculated value such that it
> doesn't make sense to have a variable for it anymore. Instead of breaking all
> of the code that uses the variable by changing it a function, you change it to
> be a property function, and all of the code which used it continues to compile
> and work just fine.
>
> D's properties need some work before that will really work properly (e.g.
> http://d.puremagic.com/issues/show_bug.cgi?id=8006 ), but it works just fine
> with property implementations in other languages (e.g. C#).
>
> - Jonathan M Davis

++ to Mr. Davis!

This is much more concise way of stating what I was trying to say. And it is an argument that should NOT be lightly dismissed, it is a very real, very common problem.

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

On Thu, 24 Jan 2013 12:58:41 -0800, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 1/24/13 3:45 PM, Nick Sabalausky wrote:
>> On Thu, 24 Jan 2013 12:51:32 -0500
>> Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org>  wrote:
>> No, you merely came up with *some* specific cherry-picked examples that
>> sparked *some* debate (with most of the disagreing coming from
>> you).
>
> I simply mentioned three reasons that came to mind.
>
> Andrei

While I don't approve of Mr. Sabalausky's tone or attitude, the crux of his argument is logically sound. The problem with @property isn't @property, it's D's insistence on optional parens. If paren usage was clearly defined then this would be a non-issue. I would like to point out that I can't think of another systems/general purpose language that has an calling syntax specification as vague and convoluted as D's. C#'s is brutally simple. Java's is brutally simple. In C/C++ everything is a function or field, so, brutally simple.

Make D's calling syntax simpler, end optional parens!

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

On Thursday, 24 January 2013 at 21:00:49 UTC, Jonathan M Davis wrote:
> Being able to swap out a public variable with a function without having to
> change any code using it is arguably the primary reasons that property
> functions exist in the first place. ...

Yes, but not just any function. Side-effect free function that controls access to data. And Adam suggested it is fine to use properties to add side-effects to data assignments which is drastically different. I agree with all your words so it is probably just misunderstanding.

On Thu, 24 Jan 2013 13:14:00 -0800, mist <none@none.none> wrote:

> On Thursday, 24 January 2013 at 21:00:49 UTC, Jonathan M Davis wrote:
>> Being able to swap out a public variable with a function without having to
>> change any code using it is arguably the primary reasons that property
>> functions exist in the first place. ...
>
> Yes, but not just any function. Side-effect free function that controls access to data. And Adam suggested it is fine to use properties to add side-effects to data assignments which is drastically different. I agree with all your words so it is probably just misunderstanding.

Actually I said that in C# is possible to write properties with side-effects, but that it runs counter to guidelines. I personally do NOT write properties with side-effects.

I was attempting to illustrate in a [much to] concise way why optional parens are bad...

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

%s/Adam/eles/g