Possible @property compromise

[TommiT]

On Wednesday, 30 January 2013 at 04:39:13 UTC, Adam D. Ruppe 
wrote:
> There's times when a member variable manages its own invariant 
> and any of its values is valid for the containing class, in 
> which case the container doesn't need to further restrict 
> access to it; a public struct doesn't need to be wrapped in a 
> get function or anything.

Okay, so we have this:

struct Foo
{
     Bar bar;
}

Assume that all data in Bar is stack allocated and we can't 
change it. What if I later on realize, that I should have really 
allocated bar on the heap, because its size is too great and it 
makes Foo inconvenient in every-day use because of stack overflow 
problems. Now that everybody has already been using foo.bar 
directly, I feel really bad for not encapsulating it.

Note: that's not a problem if we have a way of saying that bar 
should behave like a property function, something like:

struct Foo
{
     @property Bar bar;
}

...and if we can create that property function later on.