On Tue, Aug 27, 2013 at 3:59 AM, David Jeske <[email protected]> wrote:
> On Mon, Aug 26, 2013 at 10:43 PM, Jonathan S. Shapiro <[email protected]>wrote: > >> 1. Fixed-size arrays in the safe language subset. The fact that the * >> fixed* keyword is unsafe is just plain irredeemably stupid. I'm told >> that fixed arrays were planned for CLR 1.0, didn't make the cut, and were >> dropped. It's time. Oh. They shouldn't be limited to non-reference types >> either. >> > > It is an odd omission. Would you place them directly into records with no > indirection, such that each generic sized-array parameter would need it's > own parametric instantiation? > Absolutely inlined into records with no indirection. I'm not sure why we are talking about generics here, though. It's just a matter of dropping the "fixed" keyword on fixed int32 fiveInts[5] and then having the compiler implement the type. While I'm whining, the legal element types shouldn't be restricted to non-reference types. That restriction is a consequence of the unsafe implementation. There really aren't that many use cases for this that aren't handled well by heap-allocated vectors. But some of those use cases are actually important. > 4. A proper region typing system >> > > What does this mean in the context of shared-memory-threading? Or would it > only be for single-threaded apartments? > Regions deal with lifetimes. They are pretty much orthogonal to threading concerns. > > >> 6. Type classes, to be used as WHERE constraints >> > > Sounds nice. Do you intend them to be usable as where constraints for any > type specification or just for generic parameters? > I hadn't thought that far, but I was thinking in terms of something like : where TC(T1, T2, ... Tn) in which TC is a type class name and T1..Tn are arbitrary types. That is: a general multi-parameter type relation. In a certain sense, the *current* where clauses can be viewed as a convenience sugaring for the DerivedFrom type class relation. 11. some form of "const/readonly" modifier for parameters, as opposed to > fields. > Yes. When I talked about readonly, I intended to be saying that it should be implemented in the type system generally. > 12. type-checked typedefs > You scoundrel! :-) And perhaps enums as proper types as well. Sugar, but damned useful sugar in systems code. > 13. explicitly non-escaping "borrowed" delegates, and efficient iterators > exposing value-types byref, to avoid copying > I'd just as soon get rid of delegates and replace them with first-class procedures. But yes, the notion of a NoEscape effect is attractive. > 15. extension methods with byref this parameters (VB.NET has it), to > support value-type extension methods > Yup. > 17. some form of static metaprogramming over language types... such as a > loop over the fields of a struct which is compile-time instantiated, rather > than using runtime reflection. > There's a whole discussion to be had on compile-time reflection. shap > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
