Revised RFC on range design for D2

[Chris R. Miller]

Andrei Alexandrescu wrote:
> 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?

Improper use of properties make code that looks ambiguous.  Is that a 
public member or a method?  It reduces codebase coherency, which is 
normally not a huge problem except when new programmers are reading 
through the code to see how it works.  If someone mistook that method 
call via property as a member, then they might use it as such in code 
they write.  Because it's actually a method, it has the potential to 
rope in serious amounts of processor work.

It's the same reason you don't want to overload simple operators in C++ 
with potentially large algorithms, since it creates an illusion that the 
operator is really a simple operation when in fact it could be quite 
tedious.  This is - of course - a matter of practice with C++, and isn't 
a language requirement, but it does illustrate that it's something to be 
conscious of.  Similarly, you wouldn't want to load up a D invariant 
with a lot of hard processor work, since that would incur a lot of 
overhead following each public function call.  There's nothing 
explicitly wrong about doing it, it's just bad practice (according to some).

I hope that was coherent.  I believe I read about it in /Code Complete/, 
if you want a source.