Revised RFC on range design for D2

Bruno Medeiros brunodomedeiros+spam at com.gmail
Mon Oct 6 05:04:09 PDT 2008


Andrei Alexandrescu wrote:
> Bruno Medeiros wrote:
>> Andrei Alexandrescu wrote:
>> Yes, we would need an alternate mechanism for properties - an addition 
>> to the language. And it's quite true that it's likely there would be 
>> disagreement in the "lot of people" about that. But there is only one 
>> way to be sure, so we could at least try! Would you and Walter at 
>> least consider this, and see if we could find an alternative that 
>> satisfies a fair number of people? Try without compromise.
> 
> What I'd consider is not that important. I do know what Walter's 
> viewpoint is, and that is that there are plenty of bigger rocks to move.
> 

By "taking into consideration" I don't mean that he would implemented it 
right away. It's clear there are a lot of work being done in other 
important features. (Still, some of the property proposals, like the one 
below, could be quite simple if not trivial to implement)

>> In fact, I'm also not a fan of those complex property mechanisms, à lá 
>> C#. I think a fair candidate would be Bill Baxter's proposal, the 
>> 'property' keyword:
>>
>>   property int foo() { return _foo; };
>>   property void foo(int foo) { _foo = foo; };
>>
>> The property keyword would make a function callable *only* as a 
>> property syntax (either as reading, 'bar = foo;', or as writing, 'foo 
>> = 42;'). A function signature which was not adequate for property 
>> access would be compile-time error.
>> This proposal fixes the ambiguities issues, and require *minimal 
>> changes* to the language, both in terms of syntax and semantics!
> 
> Then what would obj.fun mean when fun is not a property?
> 
> Andrei
> 

Good question. One option would be for obj.fun to be a compile error, as 
mentioned.
But other yet, and cleaner IMO is for obj.fun to be the delegate value, 
ie, the same as the current "&obj.fun". The proposal's &obj.fun could be 
the same as obj.fun, as a deprecated syntax for backward compatibility.


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D


More information about the Digitalmars-d-announce mailing list