Revised RFC on range design for D2

[Benji Smith]

Andrei Alexandrescu wrote:
> 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

Me too.

My previous use of the word "consistency" was perhaps a little sloppy, 
but I think Bill explains my thoughts to a tee.

I'd be happiest if we could strengthen the semantics of properties, to 
make them indistinguishable from fields (from the class consumer's 
perspective). If we can't accomplish that, I'd rather do without the 
optional-parentheses and "x.prop = 3" tricks, using functions instead of 
properties.

--benji