Revised RFC on range design for D2

[Andrei Alexandrescu]

Michel Fortin wrote:
> On 2008-09-28 19:32:43 -0400, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> said:
> 
>> struct S2
>> {
>>      void prop(int x);
>>      int prop();
>> }
>>
>> S2 s2;
>> s2.prop = 42; // fine, prop is a property because it also has a getter
>>
>> This solution does not require any syntactic addition. Its drawback is 
>> that it makes it hard to define write-only properties. Are they 
>> important?
> 
> I think having a function returing *the same type* is probably too much. 
> What about this case:
> 
> struct S
> {
>     string str();
>     void str(string s);
>     void str(wstring s);
>     void str(dstring s);
> }
> 
> In this case, you can only do "str = x;" when x is an UTF-8 string. 
> Setting UTF-16 and UTF-32 would (sadly) require using the parenthesis 
> syntax under your proposal. So I think you should not check for the 
> return type of the getter, just if there is a function of the same name 
> with no parameter, to determine if the "=" syntax can be used.

Great point. I think the rule suggested in my latest post convers this. 
The rule was, if you can call s.str(s.str) then str is a property and 
allows the syntax "=". After than overloading will take care of all else.

> ...
> 
> Hum, and what do you do with this:
> 
> 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.)

> And also, if you keep checking the return type of the getter, what about 
> this:
> 
> struct S2
> {
>     void prop(Object x);
>     const(Object) prop();
> }
> 
> Should "prop = new Object;" be legal or not?

Great question - quite an arrow in the suggestion's Achille's tendon. 
Since I can't write s.prop(s.prop), that property would be ruled out.

This may in fact be a good thing. It would be nice to provide generic 
code with the guarantee that if the save some property of an object, 
they can restore it later:

void generic(Node)(Node obj) {
    auto save = obj.indentLevel;
    scope(exit) obj.indentLevel = save;
    ...
}

> What if prop() was 
> returning an invariant(Object) instead (for which there is no allowed 
> implicit conversions)?

Under the proposal entity.prop(entity.prop), that won't compile. (I will 
note that invariant(Object) does convert to const(Object)).

> And what if there are two overloads for the 
> setter: one with an invariant(Object) and one with an Object (mutable)? 
> Are both allowed to be called with "="?

Under the proposal entity.prop(entity.prop), that would compile.

> Then you should probably disallow "ref" and "out" too in the setter.

Consider:

struct ArrayAppender {
     ref Array host;
     void host(ref Array);
}

That should work as property, ain't it?

(Walter has introduced ref returns; I'm already working on an alpha that 
has the feature. Of course I found bugs, too. :o))

> I'm 
> not sure either about what you'll do once "shared" gets in the picture. 
> (And ain't "scope" comming at some point too?)

Same test entity.prop(entity.prop) rules'em all.

> Also, what if one or the other is a static function?

Depends on how you call it. If you call it with an object in the first 
place, it works. If not, it doesn't.

> And what if you 
> have an invariant(S2) and prop(Object x) is accessible (because it is 
> invariant) while prop() is not (because not invariant), should the "=" 
> syntax apply anyway?
> 
> ...
> 
> Basically what I want to illustrate is that another drawback of this 
> solution is that it will probably not be as straitforward to define, and 
> then understand, as it seem at first glance.

I think it is very easy to define and moderately hard to implement.

> The current syntax, with all its drawbacks, has the advantage of being 
> very easy to understand: using "=" works all the time and it's the 
> caller's responsibility to use the syntax which express better what he 
> is doing. Personally, I have no problem with that.

I'm not crazy about the syntax, but if it has notable advantages, sure.


Andrei