Revised RFC on range design for D2

[Andrei Alexandrescu]

Bill Baxter wrote:
> On Thu, Oct 2, 2008 at 8:26 PM, Michel Fortin <michel.fortin at michelf.com> wrote:
>> Compare this with properties which have exactly the same performance,
>> memory, and flexibility implications as regular functions. The only
>> difference between a property and a function is the meaning the author give
>> to it, and that meaning vary between authors and contexts. Which means that
>> from the API user point of view, something being a property or a function
>> doesn't mean much... except of course that the user has to remember if
>> Singleton.Instance is a property or a function before using it, or else
>> suffer some useless compiler errors.
> 
> Good points.
> 
> I think this discussion is diverging a little far from the real raison
> d'etre for property syntax, though.  They are there in the first place
> not to save the typing of a few () here and there, but to allow a
> library designer to start with a plain field when that suffices and
> transition to a function later if that becomes necessary, without
> breaking client code.  And there's where we can invoke a grand
> principle of software design as Andrei would have us do:
> 
> * Changing implementation details should not affect client code.
> 
> Ok I guess that's a software design principle, not language design but
> I guess I can say the underlying language principle is that the a good
> language should facilitate good software design.
> 
> This one has to trump principles about economy of syntax and such,
> because the point of having a language in the first place is to make
> writing software easier/better/faster.
> 
> More specifically this is a case of where we want syntax to facilitate
> making the transition from a simple field to something with some logic
> too.  So what can we hope to get from the language to support this in
> the best way possible.   These two conclusions seem pretty obvious to
> me:
> 
> 1) The "fake" field's behavior should be indistinguishable from real
> field behavior in as many circumstances as possible.  This prevents
> client code from  having to change.  This is why things like += on a
> property should be transformed by the compiler.
> 2) In situations where behavior does differ from that of a real field,
> a compiler error should occur at the point of usage.  This prevents
> nasty surprises where code silently starts behaving incorrectly.  This
> suggests that something like attempting to take the address of the
> field should be a syntax error if the field is turned into a property
> function.   (This probably already happens in most cases since a
> function pointer won't usually be interchangeable with an int pointer
> or whatever it was before)
> 
> Anyway, the point I want to make is that while it's neat that you can
> save typing a few parentheses, there are more important things, like
> being able to refactor code locally and knowing with reasonable
> certainty that all client code will either still work correctly or
> fail to compile.
> 
> Going by these principles could lead to some interesting conclusions
> like for instance an argument that you shouldn't be able to take the
> address of a property function, or do anything else to it that exposes
> the fact that it is not, in fact, a field.

Yes, I entirely agree. I mentioned this a couple of times, but never 
explained it so well and thoroughly.

Andrei