Inner types for F#
For types that are never to escape to the external API it would be awesome to contain them inside of other types. Less cluttered.
Class Library sometimes uses this feature. ex WebBrowser.WebBrowserSite.
WebBrowser.WebBrowserSite is protected, so inner type must need to override this class.
Justin Magaram commented
Completely agree. I've got some complicated algorithms inside some let bindings. I can use tuples but since the components aren't labeled it is trickier to write the algorithm correctly. I'd love to be able to define a record inside a let binding just for use inside the algorithm.
Ed Brey commented
Even putting types inside let bindings is helpful sometimes to avoid the trade-off of using complex tuples vs. giving up on keeping related code localized.
Johann Deneux commented
Inner types are necessary if you want to reimplement C# libraries in F#, maintaining the exact same API, which is necessary if you can't modify clients of the libraries in question.
David Thayer commented
The one use case for this that signature files do not solve is when the contained type is parameterized on the containing type such as creating an object type specific error object that allows the type to tell you which instantiation of a generic type threw the error. ex. MyBadTableKey<'keyType>. Currrently you have to use MyBadTableKey<object> and then box and unbox objects to pass the value and retrieve the value.
Jorge Ortega commented
I believe we can get the same behavior using a signature file to hide away types, which some would argue can be a little clearer then having nested classes.