+1 for typed typedefs .. too many ints in C it would be very usefull even in business apps to have say typedef int CustomerKey ; will stop a lot of bugs when you use the wrong foreign key in CRUD code.
Enums im mixed on , using them for C# is normally a problem but for interop and using [Flags] its gold , as well as the fact you need them for many .NET standlibs so id leave them . Maybe just add an ENum type in the new standard lib but leave enums for interop. Speaking of which will you retain compatability with existing .NET libs ... ? > Can a "proper region typing system" (or Rush-ish named lifetimes) be done > without CLR changes? Or at least changes to CLR verification? It feels like > named-lifetimes could be done only with verification changes, but if I > understand your definition of a "proper region typing system" (which is not > necessarily the case), it seems to require deep CLR changes. Does it not? > This is the big question for me as well , but it seems more compiler to CIL related than anything else .. Why does it need CLR changes ? The region unwinding would just be explicit CIL stack unload instructions. You may not eb able to do eveything ( eg second stack) but you should be able to do region analaysis , unwinding , move GC heap objects to stack objects, "Fixed-sized arrays as safe types presumably requires fixed-sized-arrays as generic type-paramaters, which requires CLR support parametric instantiation of type-and-length." change the type fixed int32 fiveInts[5] internally to fixed: fixedArray< <int> ,Nat<5> > fiveInts. Or use some bits in the ptr for length than unpack it in the method. re tail calls http://connect.microsoft.com/VisualStudio/feedback/details/166013/c-compiler-should-optimize-tail-calls " Thanks for the suggestion. We've considered emiting tail call instructions at a number of points in the development of the C# compiler. However, there are some subtle issues which have pushed us to avoid this so far: 1) There is actually a non-trivial overhead cost to using the .tail instruction in the CLR (it is not just a jump instruction as tail calls ultimately become in many less strict environments such as functional language runtime environments where tail calls are heavily optimized). 2) There are few real C# methods where it would be legal to emit tail calls (other languages encourage coding patterns which have more tail recursion, and many that rely heavily on tail call optimization actually do global re-writing (such as Continuation Passing transformations) to increase the amount of tail recursion). 3) Partly because of 2), cases where C# methods stack overflow due to deep recursion that should have succeeded are fairly rare." All that said, we continue to look at this, and we may in a future release of the compiler find some patterns where it makes sense to emit .tail instructions. there is a .tail call in the CLR Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
