andrgin2

I think this is a great feature in Visual Basic because you will really save lots of code and it will be very easy to replace an auto implemented property with a normal property afterwards (adding additional checks and cleanup work for setters, or implementing extra logic for getters if you change the field).

 

There is only one problem:

Very often it is better to access fields directly because you want to bypass any validation checks that my be implemented in the property someday. An example for this is the constructor where you do not have valid data yet or some other situations.

It is also good for readabilty of Code if you have your global Fields of a Class starting with a "_", while local variables in a function do not have it.

I have seen you can access the private fields directly very nicely, but there is no intellisense support for this. If you type Me._Last in the construtor there is no entry for Me._Lastname.

Why dont give you the user more control over the amount of threads. In a for or for each loop you can make an optional parameter with the maximum threadcount. When working with Tasks you could make a property "expected load" where the user can define, how much load can be done at the same time. This gives the user full control but is much easier than making a synchronized Queue with work and start x threads like I did. Synchronized queue has no generic support and I have to build an extra class with all the information the thread needs.
For simple Tasks where each one is doing different work (the same work with only different data is better done with a for each loop I think) the count cant be so big. If there are 20 threads running on a dual core machine this does not kill performance, only if 2K threads are running.