Why? Other than "breaking code".

Simen Kjaeraas wrote:

>> Seriously
[...]
> whereas yours does not

To me it is a syntactical change only. Where can I find the semantical change?

And ... did you overlook the "seriously".

-manfred

On 2013-01-24 23:26, Robert wrote:
> Apart from +=, ++, what breaks compatibility of fields and properties,
> is that you can't take the address of a property, but of a field (as
> already mentioned). To increase compatibility and in order to avoid
> breaking peoples' code, when a field is changed to a property, maybe,
> simply offer the possibility to declare fields to be a property too,
> with @property. And make it so that the access to such a field behaves
> exactly the same as to a property: No address taking, and as long as
> properties don't support ++, +=, ... maybe even forbid those.
>
> Example:
>
> @property int a;
>
> would be completely equivalent to:
>
> int a_;
>
> @property int a() {
> return a_;
> }
> @property int a(int new_a) {
>   a_=new_a;
>   return a_;
> }

I really like this. Although this is not really what the rest of the thread is about can could perhaps be introduced separately.

What I like about this is that I get a virtual property and doesn't have to write the boiler plate code by hand.

> I think this would suffice to make the property concept really sound and
> working in practice.
>
> If, this is considered a good thing, I could create yet another property
> DIP.
>
> Another thing I am wondering, will this still be possible:
>
> void myProperty(int a) @property {}
>
> void function(int) dg=&myProperty;
>
> Or in other words, will taking the address of a property method still be
> possible? I think it would be quite sensible and useful (for e.g.
> std.signals), taking the address of a transient return value does not
> make any sense anyway, so no ambiguity here. On the other hand it would
> break compatibility with fields again. So if we also want to make sure
> the way back (from property methods to field) works, disallowing taking
> the address might be the way to go for a finally proper implementation.
>
> To the C# experts: How does C# solve those two issues?

Scala solves the first one by always implementing public instance variables as virtual functions.

-- 
/Jacob Carlborg

On 2013-01-24 23:41, Adam Wilson wrote:

> The one problem with your example is that you haven't defined a way to
> make the property read-only/write-only like in C#.

@property(get, set) int a;
@property(get) int b;
@property(set) int c;
@property int d; // same as "a"

-- 
/Jacob Carlborg

On 2013-01-24 23:48, Adam Wilson wrote:

> The syntax provides no way to define read-only or write-only properties.
> Other than that I love it, but I am a biased C# guy.

@property(get, set) int a;
@property(get) int b;
@property(set) int c;
@property int d; // same as "a"

-- 
/Jacob Carlborg

On 2013-01-25 01:12, Andrei Alexandrescu wrote:

>> public Action temp { get; set; }
>> public Action Event { get { return temp; } }
>> t.Event; //returns the delegate
>> t.Event(); //calls the delegate.
>>
>> Simple, clean, clear, concise. No problems with optional parens.
>>
>> (Action is a delegate in C#)
>
> This looks essentially the same as Walter's proposal.

This code contains explicit properties. Walter's proposal was to remove the explicit properties.

-- 
/Jacob Carlborg

On 2013-01-25 03:19, Andrei Alexandrescu wrote:

> I agree parallels with natural language are tenuous.

No, they're not. Perhaps in this particular case. But code is for humans to be able to read and write. That's why it looks similar to natural languages. Otherwise we would just program in machine code. The computer doesn't really care.

-- 
/Jacob Carlborg

On 2013-01-25 10:16, deadalnix wrote:

> Assignation is right associative, so it is equivalent to :
> auto i = (f = 3);
>
> The setter is called.

That's what I'm saying, the setter needs to be able to return something and not just void.

-- 
/Jacob Carlborg

On 2013-01-25 10:49, deadalnix wrote:

> From what I see on CofeeScript website, it has a VERY different
> semantic than D on function.

How do you mean? Well it has the same semantics as JavaScript since it's compiled to JavaScript.

-- 
/Jacob Carlborg

On Friday, 25 January 2013 at 13:18:47 UTC, Jacob Carlborg wrote:
> On 2013-01-25 10:16, deadalnix wrote:
>
>> Assignation is right associative, so it is equivalent to :
>> auto i = (f = 3);
>>
>> The setter is called.
>
> That's what I'm saying, the setter needs to be able to return something and not just void.

Hm, shouldn't it be processed like that:
1) evaluate "f = 3", setter called
2) evaluate "(f = 3)" -> evaluate "f" -> getter called
3) evaluate "auto i = ", setter called
?