enricosada
commented
7 years ago Closed dsyme closed 6 years ago
enricosada
commented
7 years ago 
dsyme
commented
7 years ago @enricosada I edited your comments above to remove spelling mistakes. If it is possible for you to reduce the comment a bit to get right down to the essentials that would be great.
dsyme
commented
7 years ago @enricosada I rearranged your comment a little to bring the real questions under discussion closer to the top, and put some of the background information/assumptions at the bottom.
enricosada
commented
7 years ago I'll trim it, i am always too verbose writing these retrospectives. Is not the "I didn't have time to write a short letter, so I wrote a long one instead", is more about adding too much details maybe useful later as reference.
Thx a lot for cleanup @dsyme
dsyme
commented
7 years ago @enricosada :) no problem, my pleasure :)
KevinRansom
commented
7 years ago @enricosada
From an engineering perspective: Adding F# support into the dotnet SDK as a first class feature with F# unit tests and support for both desktop build using msbuild and dotnet.exe in the SDK repo means that when the SDK team make changes to the SDK they will also fix up the F# support before they check it in.
Having the dotnet cli build test and deploy F# means that, before they check-in stuff that breaks us they will have to fix it or give us a heads up.
Crossgen is goodness.
What we have needs to work well under CPS, following the C#/VB model ensures that F# will always feel just as first class as those two languages. Because we are a smaller, much more distributed team, we need to follow their model on most of these things. Except when we have a clearly superior approach of course.
The SDK, the CLI and the templating projects are all open source, and will welcome contributions aimed at improving our F# support.
From a third party developer perspective: Deploying the F# compiler with dotnet.exe makes F# as first class on coreclr as C# and VB.
Having the same project structure as C# and VB means that a C# developer can easily reason about what an F# project will do when compiled. The major differences between F# and C# in the SDK will be the requirement to list source files. C# and VB developers are spared that duty.
The work that you did on the FSharp.Sdk was trail-blazing and significantly improved the F# coreclr story, however, C# and VB were significantly better integrated into the coreclr and msbuild dotnet eco-systems, the new approach aligns us more closely.
To close, I am grateful for the work that you have done, it has been important and significant, as well as driving F# on the coreclr forward significantly, however, we think that deploying F# with dotnet.exe will improve the experience of using F# on the coreclr.
Kevin
vasily-kirichenko
commented
7 years ago Deploying the F# compiler with dotnet.exe makes F# as first class on coreclr as C# and VB.
This is the first really good news in this year. Thanks you.
0x53A
commented
7 years ago With the old fsproj, I currently use https://www.nuget.org/packages/FSharp.Compiler.Tools. That enables me to use F# vLatest with Visual Studio 2015 or even lower.
Will I still be able to override the compiler? You mentioned somewhere that this checks for FSharp.NET.Sdk and "steps out of it's way", so will FSharp.NET.Sdk continue to be updated to the latest fsc, parallel to this?
Basically, I want to be able to use the "nightly" compiler with any version of Visual Studio / dotnet cli.
Edit: I read enricos post again, and am I correct that I could just continue to reference FSharp.Compiler.Tools and everything "will work"?
enricosada
commented
7 years ago I'll update my comment as @dsyme request, because was more feedback driven and not actionable enough.
I'll convert it to a question list for vf# team (@dsyme @KevinRansom @cartermp etc.) so i hope it is easier to discuss and answer. Let's focus on the how and details, because is just another PR for me, who can improved (not just by myself) and enhance final deliverable.
First to automatically copy c# or vb only is, IMHO, not enough because we are a different community and repo. Many things can be best handled if split as single discussions not using a big one (il.e. it's not just all about "in band" v "bundled" - this is too generic and minimizes the opportunity for discussion, with lot of noise). Let's try to separate the issues.
If "in band" mean bundles like VS/mono/dotnetcli CANNOT release a new version if fsc is not ready, otherwise is exactly the current situation. Otherwise is just bundle fsc and target and is ok too.
The .net teams are really collaborative already (and dotnet/cli contains test for F# projects in CI since preview2 , go figure), and they are proactive to maintain and enhance, to ask, point to issue and they communicate a lot (see https://github.com/dotnet/netcorecli-fsc/issues who contains examples), so thx a lot to @livarcocc @eerhardt @piotrpMSFT @dsplaisted @mlorbetske @nosami @mrward @mmitche, and previous owners/menbers .
Personally, while i value a thing like parity, that doesnt matter it cannot be adapted a bit to help with current f# situation: we have a required lib, a special community and lot more OSS effort than others (focused on grumpy tooling too)
enricosada
commented
7 years ago I'd like to give an overview of current status first, some context, and finally some tradeoff choices to evaluate
The question about how to support F# in the .NET Core world is a long argument, because it is not just about the .NET Core/NETStandard but also affects:
AFAIK this new tooling (new fsproj) should completely replace old F# tooling (the old fsproj). So it will also be used to build net40 or Xamarin mobile apps etc , we the tooling is finally available and all projects converted. The new fsproj will support multiple target framework in same project (crossgen).
This new fsproj is also used to create a nuget package (Pack target). Other targets are used for other sdk/tools (trim, etc).
Some scenarios require some additional components to be installed. For example, mono is required to build (not just execute) the net4* target framework. This is important when everyone expects msbuild /t:Pack (aliased as dotnet pack in cli) to just work.
nuget packages are now first class. If an assembly is not in GAC, should be in a nuget package. A nuget package support multiple target framework. Each target framework can depends on different nupkg (see ValueTuple net46 and netcore 1.6, vs net47 or netstandard20).
nuget packages can modify the msbuild project with new pros/targets, using new msbuild sdk extensibility who auto import build/{packageName}.props and build/{packageName}.targets from nupkgs
I'll start from the user experience, because is easier to see the main goal: default templates of lib/console should give the best practices, and not cripple integrations.
Templates are the starting point (File -> New or dotnet new -lang f#). Now
dotnet/templating gives the default templates for editors (like VS) or dotnet cli or others.The template engine and the default templates (lib/console/etc) should be shared (they are just nuget pkgs), but the bundling may change (so VS has these in a different location than dotnetcli).
For templates, the actual SDK used is an implementation detail (FSharp.NET.Sdk+Microsoft.NET.Sdk or just Microsoft.NET.Sdk).
But I want to highlight that there other very real choices lurking here which we shouldn't avoid:
FSharp.Core.dll to use.fsc compiler to use.These shape both templates and the implementation.
These two are the two big categories (lib and console).
And tradeoff doenst need to be the same. I value good defaults, but also plan for resilience to bug, if is needed (there are unknown unknowns)
A lib in modern .NET (unless is a bcl assembly) is packaged as a nuget Package (nupkg).
I think of FSharp.Core.dll as normal lib (but mandatory) so packaging may be a nupkg (like Fsharp.Core nupkg).
This is really important because make it transparent or at least normal for a lot of tooling steps (restore, pack, publish) and the nupkg format support already advanced scenarios (multiple target fw, additional files, add new props/target to project)
Using <Reference to local path vs a nuget package in another discussion, but i'll assume nupkg because all tradeoff i can think of are already addressed (versioning, discovery, local cache, offline scenario, metadata).
If this is in discussion, need another issue. Remark: nupkg is also for .NET Framework, is not special, is a normal target framework.
Also with new sdk (new fsproj/csproj), nupkg are first class, so easy to add (as <PackageReference or paket deps)
FSharp.Core.dll for the same target framework. Is a special case not handled, and result in messed transitive dependencies and multiple FSharp.Core.dll referenced.DisableImplicitFsharpCore (like for NETStandardLib or Microsoft.NETCore.App packages, is normal)
=> Implicit help evolve fsproj. Using same fsproj is possibile to change default version (because no lock file atm), when a new sdk is used. (for example sdk3.0 can use by default nupkg 4.2 for Fsharp.Core.dll)
=> Implicit is one line less in template.
=> Other package managers (like Paket) can just add that property as default, to manage FSharp.Core himself
=> Explicit is easier to understand, and less surprises changing sdk version (ok fsharp.core is backward compatible, but is a tradeoff)PackageReference support version ranges. Package versions in nuget are major.minor.patch (semver), that's the official versioning scheme.
=> Pinning to an exact specific version, es 4.1.9 mean if i need to update it, user need to do it manually. And is bad for resilience to bugs. And is more complicated if implicit.
=> Pinning to a wilcard .path (es 4.1.*) mean it's possibile to update it later.
=> Pinning to wilcard minor (es 4.*) mean a more strict contract for the package.
=> Implicit version may help just give the minimal supported version.
=> All bundles (VS/Mono/cli) support offline packages (to not downlaod additional stuff). So this doesnt preclude open ranges, just mean new version need to be downloaded if needed.These questions shape the best pratices, and resilience.
A Implicit pinned. So `. But usingand sameB Implicit with contract of stability. So `. But usingand sameC Explicit pinned. so <PackageRefence Version="4.1.2" />. To remove it, just remove it.D Explicit with contract of stability. Like <PackageRefence Version="4.1.*" />. To remove it, just remove it.E Add a FsharpCorePackageVersion property, so inside sdk is <PackageRefence Version="$(FsharpCorePackageVersion)" />. This is pratically the same as specifiy a package reference. BUT can be passed as env var, or command line (/p:FsharpCorePackageVersion=4.5.* or /p:FsharpCorePackageVersion=4.5.8), good for dev/testing/deterministicBoth are ok for paket, who can use DisableBundledFsharpCore or remove it and manage the package. While implicit is better for Paket (doesnt need to change the template for fsharp.core package), usually other packages are needed in fsproj template, so template need anyway to be modified
A console in .NET is usually deployed as FDD (and SCD for netcore and probably mono)
I think of fsc as normal console (but mandatory) with a stable api (command line args).
The msbuild integration is just a CoreCompile target who run it, using a Fsc task who compose fsc arguments.
An fsc built for the msbuild host runtime is needed. Each runtime has additional feature (ngen, SCD) and constraint
My Q: With fsc, shoud be more deterministict in the template? if a tradeoff is choosen (use bundled fsc), can anyway leverage nuget for discovery, versioning, updates?
FscToolPath (dir) +FscToolExe (filename) extensibility exists. Fsharp.Compiler.Tools package use these, and need to just be added to PackageReference to work. no other
=> Special case. fsc compiler for netcore is usually shared as FDD (filesize, deps) not SCD. so is a fsc.dll. FscToolPath/FscToolExe should just work, like now.Important ihmo is a value the determinism of build using different fsc version?
=> Different bundles will use differnt compilers. subtle differences, while runtime is more stable
=> Can be ok for same version of bundles, but not always the same timeframe are used (mono5.0 vs VS 2017.3 vs cli 2.0.7). different schedules
=> Annoying at runtime when user see different bugs in mono/VS but is fixed on cli. => workarounds needed
=> Usually fsc bugs (itself, f# code built) are for runtime differences or for tooling (sdk/environment) difference?A Implicit bundled. So `. But addingB Implicit pinned. So `. Like before, but fsc is normal package reference (offline cache for deploy/offline), so exists inproject.assets.jsontoo- Explicit pinned. soC Implicit with contract of stability. So ''. But inside is like <PackageRefence Version="4.1.*" />, A specific version is bundled and used (for offline/deploy/ngen), but has resilice because a new version published will be used.D Explicit with contract of stability. Like <PackageRefence Version="4.1.*" />. E Add a FscPackageVersion property, so inside sdk is <PackageRefence Version="$(FscPackageVersion)" />. This is pratically the same as specifiy a package reference. BUT can be passed as env var, or command line (/p:FscPackageVersion=4.5.* or /p:FscPackageVersion=4.5.8), good for dev/testing/deterministicBoth are ok for paket, who can manage also choose to manage the exact fsc version.
The msbuild need target/task. Target MUST be >= of task version. A target who use a property of a task who doesnt exists, fails, while a task proeprty can be defaulted if not used.
Targets doesnt change a lot, and are better if near sdk (or inside it), so i agree a lot.
While there is value to have an upgradability there too to fix bugs withtout a new sdk drop. (see for example the bug in nuget pack with dapper), doesnt happen often, but happen because unknown unknown and bugs. Wait a new sdk drop IS OK, because fixes doesnt live long anyway.
So i just add feedback.
KevinRansom
commented
7 years ago Questions:
1,2,3,4 ---- For coreclr --- nuget ... same as always. Official signed release package every VS release.
Signed previews TBD, requires a minor bit of automation probably weekly.
5. a) Dotnet cli previews daily so as soon as the next version flows there, and it's just updating a package version number.
b)oolpath overrides work now so if you build locally and publish, you can toolpath to it.
6. see 5.
7. I'm not really sure what you are asking for, but I think see 5
8 . don't understand the question
9. If you pick an FSC compiler you get that compilers behavior .... the compiler does not have a feature that enables it to reproduce the same bugs as a previous compiler. I believe C# may be trying to design such a feature ... I do not actually see the value of it.
Desktop compiler The big question, that you didn't really ask but I am sure is in your mind is what about the desktop compiler, how should it be deployed and can it be deployed separate from VS.
The will be an msbuild only deployment mechanism, similar to the VS installer but for msbuild and build tools. F# and the dotnet SDK will be an install option with that, this will enable the build server scenario.
For RedHat there will be a build from source mechanism.
enricosada
commented
7 years ago i'll add my final reply to this RFC, because while i was interested to see this as RFC so discussion before action and final decision (the R in RFC), seems (maybe i am wrong) this is now just a feedback discussion to document choices already done.
IS OK for me (i really think so).
Because is not a normal RFC ( is not language related or community components ) but about MS products (mono/vs/cli/netcore/templates), who impact community yes (templates for exaple, but also infra and extensibility), but anyway design choices are going, in the end, to happen in MS, VF# team and DevDiv.
So doesnt matter for me to continue to discuss, i'll wait for the final artifact. Or use other issues/PR if exists in vf# repo, but i think i wrote all my feedback in this issue and this reply. i dont think i can add more value to this discussion, just more words
@KevinRansom you skipped all the FSharp.Core.dll questions.
This matter a lot because you (vf# and MS) control (or you will override easly anyway) the templates for all runtimes bundled (now are shared in dotnet/templating) of both mono/VS/cli.
This impact new libs, and is the default for everyone. And in a nuget first world, deps matter.
In the RFC definition (and committed code) i see lot of scary public props. These may be just WIP or your final design. I dont know. So i can trust you (Kevin/Phil), but communication atm is a bit low. I understand you are implementing it so wip, but is not like your final idea doesnt exists. So i'll just wait to see final commit on that, and wait for "it's done" But probably will be too late (because obv is going to be time reason, no time to change, as usual). Stuff like that, who is important and impact everyone, can be improved and bugs and bad decision avoided doing a NORMAL PR with review. but doing that with multiple PR and no design is not possibile to discuss or review, because answer will be always "is WIP". So i'll just wait. And is ok, is your product, review are not mandatory, just healty ihmo, but with partial PR are hard.
- 1,2,3,4 nuget
ok, which one? i understand coreclr mean Microsoft.FSharp.Compiler.Tools.netcore. I assume that from now on.
b)oolpath overrides work now so if you build locally and publish, you can toolpath to it.
publish as SCD, so to .exe. But FDD, like now is used for netcore, doesnt work (set FscToolExe = fsc.dll, created by dotnet publish FDD ) like the on in FSharp.Compiler.Tools package will not work.
Let's ignore the overhead to launch a .cmd/.shjust to rundotnet fsc.dllvsfsc.exe(is not really needed, is just an useless slowdown and with small compilation likedotnet watch` it add up)
Release a SCD version is feasible only locally, but is really annoying if you try to have a single package, because SCD size is too big atm, and if you want to support multiple tfm is too big. FDD fix that atm.
So a feature removed by mistake (just bug) or not supported anymore?
- I'm not really sure what you are asking for, but I think see 5
Because you probably choose to use Microsoft.FSharp.Compiler.Tools.netcore package. so is a no. is ok. tradeoff.
As a note, as tradeoff possibility (what i was writing) is possibile to have a SINGLE package, who contains ALL fsc for ALL runtimes. like FSharp.Compiler.Tools does. So ppl reference the compiler package. not different packages for different runtimes. and there fsc version is always aligned (that's the WHY use a single package). Nuget as package mechanism, but a single package so easier to use.
8 . don't understand the question
Because, i assume to continue discussion, you want to do separate compiler package by target runtime (coreclr in Microsoft.FSharp.Compierl.Tools and net40 in some another bundle)
The big question, that you didn't really ask but I am sure is in your mind is what about the desktop compiler, how should it be deployed and can it be deployed separate from VS. The will be an msbuild only deployment mechanism, similar to the VS installer but for msbuild and build tools. F# and the dotnet SDK will be an install option with that, this will enable the build server scenario.
What mechanism? info? just a link or codename? OR is just a closed source not announced thing for 15.3? link for MVP if possibile under NDA? just curious.
That said: Personally, I really really hate vsix alike install mechanism for build server. Is not feasible (depends on install workflow) for deterministic build, if i need a specific installed bit in the server to work. Is like sdk now. And install F# is an option (not default), mean if i need to update it to add it, depends really on workflow and permission. build server are not always dedicated machines.
New sdk/msbuild15 support extensibility by nuget packages. BOTH TARGET/TASK AND TOOLS. i use that atm in fshar.net.sdk implementation, and not just me, other .net teams too (see test sdks) So just the base dotnet sdk (mono/cli/VS) need to be installed. the rest is installed at restore (tradeoff on WHAT may vary obv), but builtin in msbuild.
So, skipping the communication issue about the "in-banding" notice of FSharp.NET.Sdk in sdk2.0.
I add that because is in the RFC (by Kevin) to continue support it, just to clarify (because i'll maintain it, until is needed, and improving for 1.0 ) until 2.0 going rtm. And later if needed too.
Atm is just needed to repackage a fsc netcoreapp2.0 in FSharp.Compiler.Tools and sdk2.0 will compile ok (preview1 already released too).
Cannot run (build is ok) netcoreapp1.0 console app becase sdk 2.0 doesnt contains that 1.0 runtime (is another major LTS, so at max will contains 2.0+2.1), but for lib/build is ok (and 1.0 runtime can be installed separately as usual, and run built/published console app).
Having fsharp.core netstandard2.0 will make it work fully (when put in fsharp.core nupkg, will work OOTB in sdk2.0, also the already released preview1), but is not a goal for sdk2.0, dev should migrate.
About the workaround to support it in MS.FSharp.Sdk.targets are not needed probably, need to check. For sdk2.0 i can just add a condition in FSharp.NET.Sdk and use the bundled MS.FSharp.Sdk instead, if exists, so is transparent for users.
But if there is lack of communication (unlike other .net teams who go ahead creating issues, to start discussion) and just ifdef'ing like is an closed source code from an unresponsive external vendor, doesnt help minimize friction for users. That's an example where communication, collaboration and design help.
dsyme
commented
7 years ago @enricosada I'm starting to a separate RFC to discuss the FSharp.Core package issues. I think that should be separated - and we need to discuss this as a joint community.
enricosada
commented
7 years ago @dsyme agree, is important.
And please, add a point about lib/console templates too (see my Q about fsharp.core in previous https://github.com/fsharp/fslang-design/issues/188#issuecomment-301245317 i tried to summarize some options in templates too, but solution depends on needs, others exists).
Default templates matter a lot. Is the product of the choices, shape the sdk integration not the other way around.
Now all runtimes are converging to use just one sdk and a template (netstandard tfm is related but is the sdk template who matter).
So implicit/hidden choices can create lot of unneeded friction (up to cripple some scenarios and extensibility)
Ihmo if vf# team need tradeoff for VS, they need to spec their needs (not their current choosen implementation, like discussion in this RFC, but is their product so ok), so templates can be adapted to continue to use best pratices ootb and not create friction with existing ecosystem or VS users or VS supported scenarios.
Good news is we have:
dotnet new and templating), (again the FSharp.NET.Sdk doestn matter, is shaped to apply choices of packages and support template) who is used in real world, support all scenario (multi runtime mono/msbuild.exe/netcorecli), multi targetframework, integration with normal flow like publish/pack and interop, and was tuned a bit with ecosystem library authors feedback (about friction to use it).So maybe we can start with a difference comparison.
I summarized in my previous comment the open Q, but i explicit the choices as matrix
haf
commented
7 years ago dsyme
commented
7 years ago So implicit/hidden choices can create lot of unneeded friction (up to cripple some scenarios and extensibility)
I do agree this is a risk. Historically the Visual Studio "logic" for FSharp.Core has been real pain point. We should try to make sure it becomes simpler this time around (while still maintaining compat)
@enricosada The RFC focuses on the question of packages more than .NET SDK templates etc. I can only deal with one thing at a time :) thanks!
haf
commented
7 years ago Updated w/ comments in gist.
enricosada
commented
7 years ago @dsyme this can be closed afaik.
The .net sdk is updated.
I checked only .net core sdk atm, version 2.0.0-preview2-006391 who has both new templates and sdk changes.
Summarizing:
RunFsc.sh/.cmd script (who will run the specific fsc)dotnet/sdkFSharp.Core package, but is added as PackageReference (paket can disable that with an msbuild property, if needed)System.ValueTuple package is added as PackageReference if needed (paket can disable that with an msbuild property, if needed)dsyme
commented
7 years ago @enricosada @cartermp Great to know that the changes are coming through the pipe. Could you work together to update docs and entry points so they have the correct information? thanks
dsyme
commented
7 years ago I'll leave the thread open for disucssion until we're sure we've landed the whole overall experience
neoeinstein
commented
7 years ago Does this include fsc compiled and able to run on linux without requiring a 1.x runtime to be installed? I know that I was having problems trying to build F# projects using the preview1 docker image because it did not include any 1.x runtimes.
KevinRansom
commented
7 years ago @neoeinstein the latest dotnet/cli runs fsc without requiring a 1.0 runtime download. fsc is a coreapp2.0 app in the dotnet cli.
Kevin
enricosada
commented
7 years ago @neoeinstein while i can fix 2.0.0-preview1 already, need to just push a new fsharp.net.sdk, but it does matter short term?
Yes adding fsc 2.0 (just copying fsc.deps.json and dlss) in fsharp.compiler.tools will do, but is a supported scenario? atm new VF# sdk doesn support fsc as FDD added as fsharp.compiler.tools (it just run RunFsc.bat/sh and that's not enough), so will not work for a FDD fsc.
Need to make it work first.
That's my current problem.
In your scenario, your are running the preview1 docker, why what instead of LTS 1.0?
preview2 is changing the templates and sdk, ihmo is better to deprecate FSharp.NET.Sdk and just use one way to do things (the default one) to not multiply bugs and add failed expectations (i prefer to contribute to choosen way, not support fsharp.net.sdk on sdk2.0 ).
Ihmo fsharp.net.sdk should continue to work on sdk1.0 (and i'll send a bugfix about version attribute too) but that's it.
Expect to support it for sdk2.0 is not that good long term, because was not choosen as way forward.
For example, fsharp.net.sdk will not work in VS because VS doesnt bundle the sdk part (that's ok). dont want to create bugs who cannot be fixed or create false expectations.
Next 2.0.0-preview2 will change things (i tested 2.0.0-preview2-006391 and works already), so easier to focus on that (for example fix little bugs in fsac to support it https://github.com/fsharp/FsAutoComplete/issues/165 )
I am updating the https://github.com/dotnet/netcorecli-fsc/wiki now about preview1 and preview2 too.
neoeinstein
commented
7 years ago @enricosada Sounds good. I just was prospectively trying out the preview and ran into that issue. If changes are coming, I'd prefer not to be spending time on supporting the deprecated path.
Thanks.
KevinRansom
commented
7 years ago You can download a preview of the preview here:
https://github.com/dotnet/cli/tree/release/2.0.0#installers-and-binaries
From: Marcus Griep [mailto:notifications@github.com] Sent: Friday, June 9, 2017 1:38 PM To: fsharp/fslang-design fslang-design@noreply.github.com Cc: Kevin Ransom Kevin.Ransom@microsoft.com; Mention mention@noreply.github.com Subject: Re: [fsharp/fslang-design] [F# Tooling RFC-1032] Discussion: Support for F# in the dotnet sdk (#188)
@enricosadahttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fenricosada&data=02%7C01%7CKevin.Ransom%40microsoft.com%7Cf119e11ffb084e2b76cf08d4af777d19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636326375115217572&sdata=qWWWXRXgNPyK0f%2FJmS1rC%2FnrvrpWoUidl5eELxD5L1o%3D&reserved=0 Sounds good. I just was prospectively trying out the preview and ran into that issue. If changes are coming, I'd prefer not to be spending time on supporting the deprecated path.
Thanks.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ffsharp%2Ffslang-design%2Fissues%2F188%23issuecomment-307493789&data=02%7C01%7CKevin.Ransom%40microsoft.com%7Cf119e11ffb084e2b76cf08d4af777d19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636326375115217572&sdata=rfxk3peZcI8oncPL1yAozszHMdOFFy4jhlIo91xUIaE%3D&reserved=0, or mute the threadhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAE76FlXs8oHSvkA5zs1Lvcip9hgQlorpks5sCa1CgaJpZM4NRwW9&data=02%7C01%7CKevin.Ransom%40microsoft.com%7Cf119e11ffb084e2b76cf08d4af777d19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636326375115227586&sdata=LxfO05RjpgBAX8d%2FP0M4FBH9563yYCjJSuoMld41QwE%3D&reserved=0.
cartermp
commented
6 years ago Closing old discussion
Discussion thread for F# Tooling RFC- FST-1002 - Support for F# in the dotnet sdk
Despite being a tooling issue rather than a language issue, this is being treated as an F# RFC to facilitate discussion and transparency. Discussion should please be de-personalized and focus only on the technical details involved.