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.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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