Proper namespace in FSharp.Control and whether to AutoOpen
it
#84
Replies: 4 comments 1 reply
-
They add their own AutoOpen in FusionTasks They don't need to be in Microsoft.* though, would be better if they weren't |
Beta Was this translation helpful? Give feedback.
-
That is, if an assembly adds its own AutoOpen, then that indeed applies to the contents of the assembly. However we won't add such an AutoOpen here |
Beta Was this translation helpful? Give feedback.
-
No, we won't. I figured, if it is the default behavior of F#, let's go with it. Otherwise, I think it is better if people just "opt in". I used the same approach as |
Beta Was this translation helpful? Give feedback.
-
Thinking about it further, there are two things that may motivate an auto-open
I'm not totally advocating a nanesuace AutoOpen and they should very rarely be used, but having thought about it a little more it's worth leaving oprn as a question. |
Beta Was this translation helpful? Give feedback.
-
We should either target
Microsoft.FSharp.Control
orFSharp.Control
. I noticed that these namespaces, or at least the first one, is auto-opened in F# projects. According to @dsyme that shouldn't happen, so that behavior may not stick, butFusionTasks
does exhibit that behavior, see for instance this source file onAsync
extensions, which get auto-opened as soon as you project has a reference to that lib.I'll have to toy with the options a bit. Maybe the above behavior is only that way because
Async
is a type in F# Core already, butTaskSeq
isn't.Just opening this to keep track of options. Suggestions welcome.
Beta Was this translation helpful? Give feedback.
All reactions