Changes before 1.0

[Jordan Miner]

== Quote from Miles (_______ at _______.____)'s article
> Jordan Miner wrote:
> > Sometimes using the property syntax causes a compiler error:
> Properties are also broken for cases like:
> 	button.width -= 5;
> 	cursor.position++;
> This is the essence of properties (it should be completely transparent
> for the user if it is accessing a variable or calling a method), yet D
> doesn't support it properly. This has the potential to break a lot of
> code when you convert variables into properties.

Yes, it would be great if operators would work with them as well.

> > 	do {
> > 		doSomething();
> > 	} while(shouldContinue) {
> > 		doSomethingElse();
> > 	}
> Interleaving. But it would be pretty useless if the two blocks had
> different scopes.

Yeah, this was just an idea I had, and I thought that it would be easy to
implement. And it would definitely be best if both blocks had the same scope.

> > 	enum TestEnum {
> > 		Value1, Value2
> > 	}
> > 	writefln("%s", TestEnum.Value2);
> IMO, a nice way to bloat your executable code. I'd recommend placing
> this feature on a debugger, and the string repr of enums should be debug
> data. If you need string equivalence for enums, you should put them in a
> separate string array, and just index it with the enum. This allows
> better description of values and also makes l10n more straightforward.

Yes, the only time I wanted this was during debugging. Otherwise it can be
difficult to find out which enum name a variable is. .NET's docs do not say enum
values, and the source is not available. Even with D, it is more convinient to
just put writefln("%s", variable) to find out. (I don't use debuggers.) Any other
time I need the description of an enum, I would use a string array.