Revised RFC on range design for D2

[Bill Baxter]

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.

--bb