On Wed, 29 Jul 2009 18:07:19 -0400, Dimitar Kolev
<[email protected]> wrote:
Steven Schveighoffer Wrote:
On Wed, 29 Jul 2009 17:46:39 -0400, Dimitar Kolev
<[email protected]> wrote:
> Steven Schveighoffer Wrote:
>
>> On Wed, 29 Jul 2009 14:59:38 -0400, Dimitar Kolev
>> <[email protected]> wrote:
>>
>> > Steven Schveighoffer Wrote:
>> >
>> >> I don't see what advantages this has over other proposals. What
is
>> >> wrong
>> >> with a.a such that we have to resort to a#a?
>> >>
>> >> -Steve
>> >>
>> >
>> > People are crying over compilers not know which is a property and
>> which
>> > is not.
>>
>> At definition time, not usage time. I want the usage to be
identical to
>> fields, otherwise, it's not as seamless. This makes an important
>> difference for generic code.
>
> What if the compiler just expanding this to well inlining. So a#a = 3
> would just means a.a = 3 just that the compiler will have easier time
> understanding this.
If you specify a property at definition by doing int#a, then why do you
also need to specify it's a property when calling it? And if it's not
necessary, then your proposal is no different than adding a keyword. On
those merits, it's fine with me if people think int #a is better than
property int a, but I absolutely don't want to have to modify my code to
call properties using a #.
-Steve
Since when is D 2.0 frozen so that we have to take care of old D 2.0
code.
This is not an accusation just a reminder. Hope ware not going for the
mistakes of C++.
I understand that D2 is not frozen. I don't want to call properties with
a#b instead of a.b in D2, D3, or even D4, unless you can show that it
provides some benefit. From what I can tell, it does not. Sorry. I
don't mean to be harsh, but I don't think your proposal makes any sense at
all. Maybe you can answer my first question -- why do you need to call a
property with a#b when you can call it with a.b?
-Steve
