Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Option should implement Seq #716
Options should implement Seq
for u in (o:User option) do print ("Hello " + u.Name)
It's common to do something with an Option when it exists, which is why we have
For lists, arrays, sequences, and options,
This syntax is also allowed inside sequence comprehensions:
Options are missing the
Cleaner syntax for doing things with options that makes brings the iteration facilities for Options in line with List and Array.
None that I can see.
Estimated cost (XS, S, M, L, XL, XXL): S
Affidavit (please submit!)
Please tick this by placing a cross in the box:
Please tick all that apply:
Responses from linked issue:
Thanks for pinging me @cartermp I first took a lot at #705 and I don't think the proposed synthax add value. I mean if people find it to verbose to do
For the current issue, do you or @charlesroddie have an example with a Web UI code. Because I kind of fail to see where it should be use for UI declaration.
I say that because in general, when using react we try to avoid using
When working with list in views, I recommand to use
From Fable's perspective this would bring a lot of issues, because right now options are erased by Fable in the runtime (in most cases). One of the main reasons for this decision was that
I hadn't seen the #705 proposal yet, but I actually like it much more as using
I think that this proposal does the following for an option:
In some sense, it is a different way to pattern match when you want to do something effectful and it does let you combine that with
Not sure if that affects if this is possible in Fable or not.
For some context of why I mentioned this to @theprash the other day, after I was shown the initial linked proposal, I realised it applied quite nicely to what I was doing in Fable where I have 3 options to build up a UI. I had something similar to the following:
By having Option implement Seq then it would have been possible to instead do the following
@bruinbrown Yes, the code you are showing is exactly what I was speaking about.
This talk explains why we should not use
If people want to add this feature mostly/only for Fable views, then I would say we shouldn't because it prone a bad way to write views :)
Sorry I missed this comment.
Also can the Fable-inspired tag be removed here? I don't know much about Fable but I don't think it's very connected.
This is in the category of "decided in F# 1.0", so I'll close this per the guidelines.
On .NET Option.None is represented as
So there are problems both on Fable and .NET