Revised RFC on range design for D2

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
> "Andrei Alexandrescu" wrote
>>> P.S. If src.next() is too lengthy, why not just adopt ++src?
>> Because people (in wake of the recently introduced array operations) may 
>> legitimately expect that to mean "increment all elements of src".
> 
> So in one case, you believe people's assumptions aren't important, i.e. an 
> assumption that .next without parens will not change anything on the object, 
> yet in another case you believe people's assumptions are the main argument. 
> This doesn't sound consistent.

Of course it is. One expectation has to do with operational consistency 
(albeit a tad far-fetched), the other has to do with being used to a 
mistaken decision in the C language design.

> Not that I care too much :)  I am also in the camp of 'defined properties 
> should be a language feature,' but I admit to using D-properties quite 
> often.
> 
> The two things that bug me the most about D property syntax:
> 
> stuff like this:
> 
> x;
> 
> What the hell does this mean?  It looks like it does nothing.  But it could 
> be a function call.  If explicit properties were required, and x was defined 
> as a function, not a property, then x; would be a syntax error.

And what would be the advantage? I routinely use writeln; without 
feeling it makes for inferior style.

> And stuff like you said:
> 
> writefln = 3;
> 
> I've been bitten by this type of weirdness.  In Tango, in the TimeSpan 
> struct, I created several properties, one of which was:
> 
> ulong seconds();
> 
> Which converts the entire timespan to seconds.

I agree.

> I also had static 'constructors' to build time spans from common time types 
> that looked like this:
> 
> static TimeSpan seconds(ulong nseconds);
> 
> Well, someone complained that this didn't set the timespan's value to 3 
> seconds, in fact the second line does nothing but create a temporary 
> TimeSpan and throw it away:
> 
> TimeSpan ts = TimeSpan.seconds(5);
> ts.seconds = 3;
> 
> And it does seem like it should set ts to equal 3 seconds.
> 
> So we were forced to abandon the succinct syntax of the static constructors 
> and rename them fromSeconds, etc.  If properties were explicit, then I could 
> define 'hey you can only use this static constructor as a function NOT a 
> property'.  It's really those cases where you want to disallow one use or 
> the other that are desired but not allowed by the current language.

I agree.


Andrei