Revised RFC on range design for D2

[Andrei Alexandrescu]

Chris R. Miller wrote:
> 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.

Oh, besides - if computed properties are allowed, they also can perform 
arbitrary amounts of work. No?

Andrei