There are occasions where it would be extremely useful to generate types from other types.

As an example, F# interop with NHibernate is very clumsy simply because it's difficult to express types of the sort:

// C# record class
public class MyRecord
{
public virtual int Id { get; set; }
public virtual string Description { get; set; }
// etc...
}

It would be very compelling to be able to represent these as F# record types, but the CIL code generated for F# records is incompatible with NHibernate.

Perhaps it could be possible, using a type provider, to generate the POCO class above from an F# record type of the sort:

type MyRecord = { Id : int, Description : string }

The type could be generated as shown below:

type MyPocoRecord = PocoTypeProvider<MyRecord>()

I understand the difficulty of doing this at compile type.Tomas P actually explained why in a forum post (that I can't seem to find.) However, this sort of problem is the reason by the CLIMutable attribute was created, which as far as I can tell, was hard-coded directly into the F# compiler.

I can see these interop dilemmas becoming more common as F# adoption increases, especially in the enterprise where tools like NHibernate are in widespread use. There ought to be a way to address them without creating one-off CLIMutable-esque attributes per se.

The feature itself would open the door to incredibly powerful metaprogramming opportunities.

The get/set syntax for F# is very cool, but it has an issue: sometimes, the property we would like to get and set is only available through a workflow/monad, like the async workflow.

Thus, I would like to alter the typechecking rules for getters and setters. This is what they are right now (pseudocode) for the Async monad:

Property x : Async<'a>
get : unit -> Async<'a>
set : Async<'a> -> unit

IndexedProperty x : 'k -> Async<'v>
get : 'k -> Async<'v>
set : 'k -> Async<'v> -> 'unit

This is what I would like to see made possible:

type Id<'a> = 'a

Property x : Async<'a>
get : unit -> Async<'a>
set : 'a -> Async<unit>

IndexedProperty x : 'k -> Async<'v>
get : 'k -> Async<'v>
set : 'k -> 'v -> Async<unit>

When interoperating with native code, it would be handy if the NativePtr module included some additional "intrinsic" functions for taking advantage of low-level IL instructions; specifically, I'd like to be able to use 'cpblk', 'initblk', 'initobj', and 'copyobj'.

It would also be nice to have an easy way of checking for null pointer values.

Example implementation of these functions:

[<RequireQualifiedAccess>]
[<CompilationRepresentation(CompilationRepresentationFlags.ModuleSuffix)>]
module NativePtr =
[<GeneralizableValue>]
[<NoDynamicInvocation>]
[<CompiledName("Zero")>]
let inline zero<'T when 'T : unmanaged> : nativeptr<'T> =
(# "ldnull" : nativeptr<'T> #)

[<NoDynamicInvocation>]
[<CompiledName("IsNull")>]
let inline isNull<'T when 'T : unmanaged> (ptr : nativeptr<'T>) =
(# "ceq" zero<'T> ptr : bool #)

[<Unverifiable>]
[<NoDynamicInvocation>]
[<CompiledName("InitBlockInlined")>]
let inline initBlock (p : nativeptr<'T>) (value : byte) (size : uint32) =
(# "initblk" p value size #)

[<Unverifiable>]
[<NoDynamicInvocation>]
[<CompiledName("CopyBlockInlined")>]
let inline memcpy (destPtr : nativeptr<'T>) (srcPtr : nativeptr<'T>) (count : int) =
(# "cpblk" destPtr srcPtr (count * sizeof<'T>) #)

[<Unverifiable>]
[<NoDynamicInvocation>]
[<CompiledName("InitPointerInlined")>]
let inline clear (p : nativeptr<'T>) =
(# "initobj !0" type ('T) p #)

[<Unverifiable>]
[<NoDynamicInvocation>]
[<CompiledName("CopyPointerInlined")>]
let inline copy (destPtr : nativeptr<'T>) (srcPtr : nativeptr<'T>) =
(# "copyobj !0" type ('T) destPtr srcPtr #)

It would be quite useful for F# interactive to support a #package directive to allow NuGet packages to be downloaded from within the REPL. I think it would be best if this directive simply downloaded the package, unpacked it, and automatically included (#I) the correct folder based on the framework version F# interactive is running under (e.g., net45). If a package doesn't include assemblies for the specific framework version F# interactive is using, we'd automatically include the folder for the latest framework version which is compatible; e.g., if running on .NET 4.5 and a package only includes a 'net40' folder, we'd include (#I) that folder. I believe this behavior is consistent with how NuGet currently works when referencing packages from a project, e.g., in Visual Studio.

#package should not, however, automatically reference (#r) the assemblies included in the package, in case you only want to reference some of them.

Here's a usage example:

#package "ExtCore.0.8.41"
#r "ExtCore.dll";;

let substr = substring "Hello World!"
printfn "Value: %O" substr;;

I would like F# to have try/fault expressions. It would work along the same lines as the current try/with syntax, although the 'fault' block would be constrained to a return type of 'unit'. I don't expect the usage of this to be terribly common, but it would be very handy to have for logging purposes.

To answer the inevitable question, "Why not just use try/with and reraise()?" -- with try/with you're actually catching the exception; unless you remember to call reraise() to terminate all paths in the control flow within the 'with' block, you'll end up swallowing the exception and not getting the expected behavior. Similarly, if an inexperienced (or perhaps just inattentive) developer re-raises the exception with 'raise' instead of 'reraise', the stack trace information will be lost.

With try/fault, it'd be easy to log relevant information (e.g., variable values) from functions when unwinding the stack due to an exception being thrown, without the downside of being able to affect the control flow.

F# only supports explicit interface implementation with the price of unnecessary and excessive casting (also causes readability issues), potential confusion when working with other languages, and causes limitation with F#'s OOP that could be resolved without any major language change.

To expand on this, this post by Mauricio Scheffer describes the issue very well: http://bugsquash.blogspot.co.il/2009/01/implementing-interfaces-in-f.html

In addition, I'm sure I could argue that people would prefer to just write `identifier.Member` rather than `(identifier :> Type).Member` whenever the member is a signature provided by an interface.
This repeats quite a bit on average and it is messy, to say the least.

It should also be pointed out that even though F# is primarily functional (and interfaces are less of an issue), F# code is still being used from other languages, and also some domains and tasks could be easier to take on from an OO approach.
(I am also finding very high limitations with using WPF & XAML with some MVVM approaches)

Currently the workaround would be to copy-paste the signatures for every member of an interface.