Revised RFC on range design for D2

[Andrei Alexandrescu]

Michel Fortin wrote:
> On 2008-09-29 09:48:31 -0400, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> said:
> 
>>>     s.prop(s.prop) compiles disregarding applicable protection 
>>> attributes,
>>>     disregarding whether or the the getter is '= void', and disregarding
>>>     the constness of the enclosing scope (class or struct).
>>>
>>> That doesn't sound so simple, and I probably got it wrong. Can you 
>>> define it better?
>>
>> With this part I completely disagree. You artificially create 
>> complexity by bringing other rules into play that were in place before 
>> this discussion. By the same token you could add "s.prop(s.prop) 
>> compiles if s and prop are properly formed identifiers" and claim that 
>> that is an issue with properties.
>>
>> The protection attributes do their job. The = void does (will do, 
>> actually) its job. Qualifiers do their job. It's business as usual. I 
>> did not invent those rules for the sake of properties.
> 
> Ok, lets look back at what I wrote and what you replied in your previous 
> post:
> 
>>> struct S2
>>> {
>>>     void prop(int x);
>>>     private int prop();
>>> }
>>>
>>> S2 s2;
>>> s2.prop = 42; // legal or not?
>>>
>>> If it's legal, then I think it'll be used as a hack to do write-only 
>>> properties.
>>
>> It is legal because access check is done after syntactic check. (Also 
>> Walter wants to introduce the fun() = void syntax to disallow copying; 
>> that might be useful in this context too.)
> 
> But "s2.prop(s2.prop)" wouldn't compile in the context where "s2.prop = 
> 42" is called, because s2.prop is private. You say say that it doesn't 
> matter, so I take it there is an exception for protection attributes. Or 
> perhaps you're checking if "s2.prop(s2.prop)" compiles in another 
> context I don't know about.

It's my fault, I misunderstood you. Sorry. This case could go either 
way, and I agree it does add complexity to the feature. If the feature 
is thought as a syntactic rewrite (my opinion), then s2.prop = 42 should 
always rewrite into s2.prop(42), and then whether that works or not 
should be left to the protection in vigor for S2.prop(int) - public in 
this case. But it could also be argued that the access check should be 
done first, in which case the rewrite won't happen unless the code in 
question has access to S2's privates. Probably the latter is actually 
the better decision.

> About the "= void" thing, my interpretation is that it's a way to tell 
> the compiler that this function doesn't exist (like making a copy 
> constructor private in C++), but I admit I'm not sure what I'm talking 
> about here.

Yes, that is the intent.

> Anyway, my interpretation is that if you have:
> 
> struct S2
> {
>     void prop(int x);
>     int prop() = void;
> }
> 
> S2 s2;
> s2.prop;
> 
> the last line wouldn't compile since s2.prop can't be called. How can 
> "s2.prop(s2.prop)" compile then?

It should not compile. Making a function = void actively makes it 
unreachable and unusable in all contexts.

> As for the last one, I think I decided myself that it wouldn't be very 
> good for a function to be a property or not depending on the constness 
> of the object. My previous examples were badly written however. Imagine 
> you have this:
> 
> struct S2
> {
>     int prop();
>     int prop() invariant;
>     void prop(int x) const;
> }
> 
> This design is probably a little strange, but lets look at it anyway:
> 
> S2 s2;
> const(S2) constS2;
> invariant(S2) invariantS2;
> 
> s2.prop = 1; // compiles because s2.prop(s2.prop) compiles.
> constS2.prop = 1; // does not compile because const(S2).prop isn't defined
> invariantS2.prop = 1; // compiles because 
> invariantS2.prop(invariantS2.prop) compiles
> 
> Basically, whether prop(int x) is a property or not depends on the 
> various qualifiers given to prop() and the constness of S2. I think I 
> wrongly assumed you'd want to avoid this since I had in mind you'd not 
> forbid the proprety syntax when given a private accessor.

Indeed, whether or not something can be used as a property will depend 
on the qualifiers in vigor.


Andrei