Revised RFC on range design for D2

[Ian Sakkis]

Andrei Alexandrescu Wrote:

> No. Not at all. For consistency you must assert together something with 
> something else. If there are two possible and equivalent syntaxes for a 
> feature that's not lack of consistency. It's waste. We'd be talking 
> about consistency if at most "syntax in context A should be the same as 
> syntax in context B". But if the context is irrelevant to the syntax 
> then we're not quite talking about consistency.

Consistency or economy of syntax I think you are avoiding the issue which is that we need something that fulfills our requirements.

And those are:

* A way to specify that one or two functions behave exactly as a field without ambiguity. (Assignment, reading, taking an address, etc.)

* A way to specify that a function doesn't behave as a field:

writelfn = 3;

* A way to change from field to property and back without silently affecting client code (which might be out of our control).

* And some others that I can find right now.

Until now the only proposal that fits these requirements involves adding another keyword which you are reluctant to accept.

Personally I prefer the python property decorator but I don't think it fares well with the D style:

|    @Property
|    def name:
|        def fget():
|        def fset():
|        def fdel():

Probably something along the lines of C# 3.0 property declaration its better suited for D:

|    public string Name { get; set; }

And I don't think that backwards compatibility is an issue on D2. We already have several breaking changes (cost, invariant, et al) and this is an easy one to fix.

Cheers.


PS: On second reading the post has something of a harsh tone but please be assured that this isn't a personal attack. English isn't my first language.