Gui.cs: F# the ustring API makes it annoying to use F#.

[migueldeicaza]

We might need to introduce string overloads

[jpierson]

I just ran into this myself. My gut was to look for a constructor on ustring that takes a string literal now I'm looking for the most reasonable short term solution.

[jpierson]

To help explain to others who may not be fully in on what makes this annoying in F# is to look at an example case in F# from the Sample in the README where we are instantiating an instance of the Terminal.Gui.Window class.

```C#
var win = new Window (new Rect (0, 1, top.Frame.Width, top.Frame.Height-1), "MyApp");

```F#
let win = new Window(new Rect(0, 1, top.Frame.Width, top.Frame.Height - 1), NStack.ustring.op_Implicit "MyApp")

Notice the need in the F# example to call the underlying compiled name for the implicit string to ustring operator op_Implicit. Not the end of the world but having this bit of the code read something like ustring "MyApp" without having to introduce any helper functions would make this library feel a bit more natural in F#.

[ebekker]

Isn't the more functional approach in F# to pipe the value, such as "foobar" |> ustring?

[jpierson]

@ebekker, that definitely looks valid as long as ustring is not a constructor but whether it's more functional or not I think is subjective. I typically use the pipe forward operator for larger chains of transformations.

In this case since there are no additional parenthesis for needed for the prefix notation I think it comes down to which one is less characters and thus noise.

```F#
"foobar" |> ustring

v.s.

```f#
ustring "foobar"

[migueldeicaza]

Yeah, I think I might need to make ustring just an internal API, and an optional API everywhere :-(

[asik]

You run into the same issue using SharpDX. That's why I always define an implicit conversion operator:

let inline (!>) (x:^a) : ^b = ((^a or ^b) : (static member op_Implicit : ^a -> ^b) x)

Then you just write !> "blabla" and don't need to worry what the target type is.
Example usage here:
https://gist.github.com/asik/ce229023fb0eb153bde6aacc384d8ac4

Agreed it would be better to avoid needing this, but just to say there's a half-decent workaround.