Revised RFC on range design for D2

[Michel Fortin]

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.

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. 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?

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.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/