Revised RFC on range design for D2

[Denis Koroskin]

On Sun, 28 Sep 2008 05:45:58 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Sergey Gromov wrote:
>> Sat, 27 Sep 2008 15:19:01 -0500,
>> Andrei Alexandrescu wrote:
>>> My point is that I agree with all concerns you are raising but I am not
>>> sure they warrant adding a language feature.
>>  I hoped for some reason that these features could simplify the  
>> compiler.  Now when I think about it I conclude that I was probably  
>> wrong.  Explicit properties is definitely a feature, even though it  
>> seems easy to implement. Injectons could help if Walter were forced  
>> into supporting different scoping rules for unified call syntax, but if  
>> a.f(b) stays strictly a sugar for f(a,b) this feature helps nothing  
>> from a compiler standpoint.
>>  So I'll probably agree that these features don't add much to the  
>> language, as D doesn't add much to C except safety, productivity,  
>> maintainability and claritiy.  The clarity/maintainability vs  
>> genericity is a tradeoff which is completely in Walter's hands.
>
> Very wise words.
>
> I think we all agree that there are some annoyances related to the whole  
> property business, among which the main one is:
>
> writeln = 4;
>
> That is quite indefensible :o|. I consider the others rather minor, but  
> that's just a personal opinion.
>
> How about this. Maybe if we attacked this annoyance in particular, that  
> would be a large bang for the buck without a landslide change in the  
> compiler. We only need some way to inform the compiler, "yes, it's ok to  
> call a.b(c) as a.b = c". Ideas?
>
>
> Andrei

I think property syntax should be disallowed by default. Most of the  
functions aren't expected to be used as a property, anyway.
It would break the code, yes, but it is very easy to fix.

Solution of my preference:

class Foo
{
     // allow property syntax:
     property void bar(int baz); // allows "foo.bar = 42;"

     // allow omitting parens
     property int bar();         // allows writing "int x = foo.bar;"
}

Think long term, don't be afraid to break existing code and introduce new  
features if they improve the language signaficantly. Wrong decision made  
today may make huge negative impact over time.