Possible @property compromise

[H. S. Teoh]

On Wed, Jan 30, 2013 at 01:58:16AM +0100, Rob T wrote:
[...]
> I agree partial emulation can work, and I see you've pointed out
> that the usage of a property will have to be restricted so that it
> can work, but this means you have to mark your naked variables as
> @property ahead of time, otherwise you'll discover that you cannot
> replace a naked variable with a property without doing plenty of
> re-work.
[...]

Why do you have to mark naked variables as @property? Isn't that
redundant?

As for using struct to implement @property, I like the idea, but it does
raise tricky issues about how struct methods reference the parent
lexical scope. I don't think it's as simple as just rewriting 'this' to
point to the outer scope instead, because it breaks language
expectations that 'this' should refer to the immediately-containing
struct/class. There's bound to be corner cases that will break because
of this. Consider, for example, what happens if the inner struct's
methods need to call opAssign of the parent struct for whatever reason.

There's also the consideration of what happens if you take the address
of the 'pseudo' variable: the inner struct would then be effectively
dissociated from the parent struct, and you'll need that hidden context
pointer (along with its gotchas) in order to have things still work as
before.


T

-- 
The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a. -- Wouter Verhelst