Revised RFC on range design for D2

[Michel Fortin]

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.

...

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.

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? What if prop() was 
returning an invariant(Object) instead (for which there is no allowed 
implicit conversions)? 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 "="?

Then you should probably disallow "ref" and "out" too in the setter. 
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?)

Also, what if one or the other is a static function? 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.

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.

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