{"action":"created","issue":{"url":"https://api.github.com/repos/Microsoft/visualfsharp/issues/1254","repository_url":"https://api.github.com/repos/Microsoft/visualfsharp","labels_url":"https://api.github.com/repos/Microsoft/visualfsharp/issues/1254/labels{/name}","comments_url":"https://api.github.com/repos/Microsoft/visualfsharp/issues/1254/comments","events_url":"https://api.github.com/repos/Microsoft/visualfsharp/issues/1254/events","html_url":"https://github.com/Microsoft/visualfsharp/issues/1254","id":159463767,"number":1254,"title":"Discussion: Improve C# to F# interoperability","user":{"login":"eiriktsarpalis","id":2813363,"avatar_url":"https://avatars.githubusercontent.com/u/2813363?v=3","gravatar_id":"","url":"https://api.github.com/users/eiriktsarpalis","html_url":"https://github.com/eiriktsarpalis","followers_url":"https://api.github.com/users/eiriktsarpalis/followers","following_url":"https://api.github.com/users/eiriktsarpalis/following{/other_user}","gists_url":"https://api.github.com/users/eiriktsarpalis/gists{/gist_id}","starred_url":"https://api.github.com/users/eiriktsarpalis/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/eiriktsarpalis/subscriptions","organizations_url":"https://api.github.com/users/eiriktsarpalis/orgs","repos_url":"https://api.github.com/users/eiriktsarpalis/repos","events_url":"https://api.github.com/users/eiriktsarpalis/events{/privacy}","received_events_url":"https://api.github.com/users/eiriktsarpalis/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/Microsoft/visualfsharp/labels/discussion","name":"discussion","color":"fbca04"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":26,"created_at":"2016-06-09T17:26:08Z","updated_at":"2016-07-22T12:49:54Z","closed_at":null,"body":"I'm starting this issue to discuss potential changes that could improve C# to F# interoperability. \r\nF# to C# interoperability works fine, but anyone who's ever used an F# library API from C# might have come across some of the following issues:\r\n\r\n### Optional parameters\r\n\r\nAdding optional parameters to F# methods:\r\n```fsharp\r\ntype Foo =\r\n    static member Bar(?x : int) = ...\r\n```\r\nintroduces an implicit dependency on F# option types:\r\n```csharp\r\nusing Microsoft.FSharp.Core;\r\n\r\nFoo.Bar(x: FSharpOption<int>.None); // use default parameter\r\nFoo.Bar(x: FSharpOption<int>.Some(42)); // override the parameter\r\n```\r\nthis can be extremely off-putting for a non-F# user, and it gets worse as the number of optional parameters increases. The situation can be somewhat improved using [this technique](http://bugsquash.blogspot.no/2012/08/optional-parameters-interop-c-f.html), but it still is a tedious exercise to decorate all possible optional parameters in your public api with proper attributes. Even if this is done correctly, overridden parameters would still have to be wrapped in `Some`.\r\n\r\nHere are a few potential fixes:\r\n* Have the F# compiler automatically attach the Optional and DefaultValue attributes to every optional parameter it encounters. I believe that this does not introduce any backward compatibility issues.\r\n* Implement a \"CompatibleOptional\" attribute to be attached to arguments and/or method definitions. This would tell the F# compiler to attach the Optional and DefaultValue attributes to the parameters and potentially expose the parameters in a non-F# option representation: perhaps nullable for value types and null for classes.\r\n* We could perhaps sweeten the pill without making radical changes: add an FSharp.Compat namespace in FSharp.Core which implements helper methods for easily creating/wrapping values in F# option. Here's an [example](https://github.com/mbraceproject/MBrace.Core/blob/8d03c1ec87269c85fec66a903b62596e1d99e182/src/MBrace.Core/Utils/Utils.fs#L298) of how it could be done.\r\n\r\n### Lambda parameters\r\n\r\nPublic F# APIs that expose lambda parameters are virtually impossible to consume from other languages: users have to explicitly define a class that inherits `FSharpFunc<_,_>` which is extremely prohibitive. \r\n\r\nHere are a few potential solutions:\r\n* Add an FSharp.Compat namespace in FSharp.Core which implements helper methods for wrapping common delegate types in F# functions. Here's an [example](https://github.com/mbraceproject/MBrace.Core/blob/c3f8de66bc78619c839820b058717a0a57fdcdbf/src/MBrace.Core/Utils/Utils.fs#L300) of how it could be done.\r\n* Might be too far-fetched, but perhaps we could convince the roslyn team have lambda literals target F# funcs?\r\n\r\n### Conclusion\r\n\r\nPlease add any other interop issues that you might have come across. I firmly believe that the aforementioned issues seriously hurt widespread .NET adoption of good F# libraries. We can do much better than that."},"comment":{"url":"https://api.github.com/repos/Microsoft/visualfsharp/issues/comments/234534963","html_url":"https://github.com/Microsoft/visualfsharp/issues/1254#issuecomment-234534963","issue_url":"https://api.github.com/repos/Microsoft/visualfsharp/issues/1254","id":234534963,"user":{"login":"eiriktsarpalis","id":2813363,"avatar_url":"https://avatars.githubusercontent.com/u/2813363?v=3","gravatar_id":"","url":"https://api.github.com/users/eiriktsarpalis","html_url":"https://github.com/eiriktsarpalis","followers_url":"https://api.github.com/users/eiriktsarpalis/followers","following_url":"https://api.github.com/users/eiriktsarpalis/following{/other_user}","gists_url":"https://api.github.com/users/eiriktsarpalis/gists{/gist_id}","starred_url":"https://api.github.com/users/eiriktsarpalis/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/eiriktsarpalis/subscriptions","organizations_url":"https://api.github.com/users/eiriktsarpalis/orgs","repos_url":"https://api.github.com/users/eiriktsarpalis/repos","events_url":"https://api.github.com/users/eiriktsarpalis/events{/privacy}","received_events_url":"https://api.github.com/users/eiriktsarpalis/received_events","type":"User","site_admin":false},"created_at":"2016-07-22T12:49:54Z","updated_at":"2016-07-22T12:49:54Z","body":"@isaacabraham It's potentially lazy. Lists, arrays and collections are instances of IEnumerable that are materialized whereas a state machine that produces infinite streams could be considered lazy."}}
{"actor":{"display_login":"eiriktsarpalis"}}