Revised RFC on range design for D2

[Andrei Alexandrescu]

Denis Koroskin wrote:
> 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.

By whom aren't they expected?

> 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.

Without solid argument, all this is just talk. What is the negative 
impact over time?


Andrei