Tomas Grosup

> Yes, I know that to do we need `string | null | undefinedType` [fsharp/fslang-suggestions#538](https://github.com/fsharp/fslang-suggestions/issues/538). The waiting is mainly for possible changes in the runtime representation, which of course are...

Listing a few resolved+open questions I can see around: - [x] Agree on module naming, `Units` vs `Measure` => `Measure` - [x] Agree on static members vs. inlined functions w/...

> (Side note: those could also go into separate types per collection, and then collection-specific functions could be added to the respective collection modules, e.g., `Array.tag`, etc.) The naming should...

> Similar to what was discussed, but somehow dismissed in the random* functions, should we consider additions to FSharp.Core to rather be a separate assembly, and maybe not part of...

> Fwiw, as I said it before, if we are not willing to make it a generic feature of the compiler, and want to make a bunch of functions instead,...

> If collections are excluded for now on size grounds, would this API prevent a future addition where `'T What would be the implications for this with `Array.map`? I think...

> Separately: I have not had a chance to play around with this thought yet, but I wonder whether using static optimization conditionals (like for [`abs`, `sign`, `(..)`, etc.](https://github.com/dotnet/fsharp/blob/79e8531d168b4c1daf7593cf52a392799ba7a130/src/FSharp.Core/prim-types.fs#L6672-L7242)) would...

> I would also have lots of questions about that. Would we special-case exactly those functions with exactly that syntactic form of invocation? What about scenarios like these? > >...

Heads up: The following section will need a rewrite showing the logic and a few samples (I assume those can be taken from tests from the implementation PR once it...

This RFC looks good, it can be merged - the remaining comments are about preparing explicit single-place documentation for breaking changes.