CLR enhancements for future features

[leppie]

This is an open-ended discussion for enhancements to the CLR that is required to accommodate new features that cannot be implemented on the current runtime or by the compiler.

As with PEVerify, enhancements should be categorized as MD (metadata) or IL.

An example of such a CLR enhancement would be variadic generic type parameters for optimal dispatching and verification.

A hypothetical pondering thought: https://gist.github.com/leppie/f9c773ea0d69459d7021 (I dont see this happening any time soon)

[sharwell]

Generic indexer properties cannot currently be represented in metadata, even though the backing accessor methods can.

Motivating example: http://stackoverflow.com/a/2178769

[mikedn]

Heh, variadic generics would probably be cool but of all possible things you could add to the runtime this is likely the most difficult to implement.

Do you know of a language that has this (apart from C++)?

[leppie]

@mikedn: Typed Racket has it, and follows a similar approach (like C++) with their macro system, 'instantiating' an implementation based on the callsite (or explicitly).

There is the following paper that describes the implementation details: http://www.ccs.neu.edu/racket/pubs/esop09-sthf.pdf

It also has a verification of the proposed implementation (which seems to map well to IL/MD requirements).

[ashmind]

Some concept of shared type identity -- useful for merging all versions of e.g. new { X = 0, Y = "s" } into a single type over all loaded assemblies. Also useful for having anonymous function types, and maybe anonymous open generic function types.

There is TypeIdentifierAttribute, but it's limited to some interop scenarios.

[leppie]

@ashmind That almost sounds like anonymous classes in Java, but being really anonymous. Not sure if anything needs to be added to the CLR for that to happen. The compiler should be perfectly capable to determine what it needs at compile-time (and generate efficient code for it).

Example: For every anonymous class, the compiler could generate a matching interface. This type could be shared (or proxied) across assemblies/appdomains.

[ashmind]

@leppie CLR work is to merge the type from all the loaded assemblies, so you could pass an instance created in one into another. You wouldn't be able to cast using compiler alone, unless compiler would take over all the casts in the code (and even then Reflection would fail).

I am not talking about only anon types, I am talking about marking any two types form diff assemblies as identical, as long as they have identical structure.

[ashmind]

Another thing -- limited support for generics over <void>. Useful to have consistent algorithms over Func<T> and Action. The details can be ironed out, but example approach might be to return null if the void delegate return value is requested.

That might require some sort of opt-in on generic type, as T field; would be a very weird thing if T were allowed to be void in all cases.

[HaloFour]

@ashmind Reactive introduced the Unit struct for that purpose. And of course Java has the Void class. If the BCL had something similar then it could be used now, although some syntax candy to eliminate the need to return the null or Default value would be nice.

[redknightlois]

• Support for slices at the IL level. Proposal: Slicing #120
• Provide allocation primitives that allocate objects on a particular heap or memory pool. http://tirania.org/blog/archive/2012/Apr-04.html
• Numeric constraint for C where T : numeric at the IL level (not only at the language level).
• Offer "unsafe" sections that would allow performance critical code to not enforce arrays-bounds-optimization (at the expense of crashing or creating a security gap, this can be done today in Mono by using -O=unsafe). http://tirania.org/blog/archive/2012/Apr-04.html

[jods4]

@HaloFour Void in Java has nothing special really. It's a regular final class that happens to contains Void.TYPE property. When Java says the moral equivalent of Task<Void>, it's a pun on words more than anything else. At runtime it's no different than Task<object>, and the return value exists, it's null. You could definitely do that in C# today if you wanted to.

@ashmind I think accepting void as a type argument is doable but it has a big impact on JIT. Basically all functions must return a value because you never know if they are going to be used in a delegate. That can be relatively cheap if your calling convention is to pass the return value in a register ;)

For sure it would simplify the duplicated code between Task and Task<T>, or Func<T> and Action. I don't see such a fundamental change with arguably small benefits happen in the CLR :(

The only language that I know of and which does that is Javascript (functions without return values actually "return" undefined) but it's a totally different beast (dynamic language, etc.)

[redknightlois]

Access to unsafe intrinsecs via Helper Methods for useful opcodes like PREFETCHxx that can be NOP or substituted in architectures that don't support them.

[MrJul]

Support for Nullable<T> properties in attributes (with T restricted to a primitive type, that doesn't change). It's quite frustrating when you encounter it, and it's very puzzling that 1 isn't a constant in [SomeAttribute(SomeNullableInt32 = 1)] (because it's just syntactic sugar for new Nullable<int>(1)).

[HaloFour]

@MrJul That would require additional runtime support, if I recall correctly. Would null be permitted? If so, how would that be encoded given that int is encoded as 4 bytes.

[MrJul]

@HaloFour Yes, a CLR change is required, isn't that the point of this thread? :) It should be encoded as a bool and an int.

[redknightlois]

@mirhagk True, but the split in Python is not without its troubles... there are many libraries that have never been ported to 3.0 and trying to do so is a pain if you need them. Therefore, unless you are working on a 3.0 project many people choose to stick with 2.0.