Add generic print and println functions to FSharp.Core

[bbatsov]

Summary

This is another take on RFC FS-1125, following up on the closed #13597. I guess that's mostly an attempt to see if anyone's interested in driving the old proposal to the finish line. For me those would definitely be handy functions to have, but obviously they are not something very important.

The key difference from the original PR is that print and println are generic ('T -> unit) rather than string -> unit, addressing the feedback from @dsyme that a generic print function would be a better use of the "good name":

let print (value: 'T) = Console.Out.Write(string value)
let println (value: 'T) = Console.Out.WriteLine(string value)

Both functions use the existing string operator for conversion, which already:

• Uses InvariantCulture for IFormattable types (consistent with printfn, sprintf, etc.)
• Passes strings through as-is
• Falls back to .ToString() for other types (F# types like Option, List, etc. have good .ToString() overrides)

Changes

• Added print and println signatures with XML docs to fslib-extra-pervasives.fsi
• Added implementations in fslib-extra-pervasives.fs
• Added unit tests (PrintTests.fs) covering: string, int, float, bool, Option, None, list, newline behavior, and concatenation
• Updated all 4 surface area baselines

Open questions

• What about eprintf(n) and fprintf(n)? Do they generic counterparts as well?

[github-actions]

❗ Release notes required

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
src/FSharp.Core	docs/release-notes/.FSharp.Core/10.0.300.md

[vzarytovskii]

Should functions be inline?

[T-Gro]

Yes, @bbatsov pls mark at as inline so that it can specialize around the string call for certain types and avoid a .ToString() call.

[bbatsov]

Will do!

[vzarytovskii]

Will also probably want IL baseline tests to make sure correct overloads are getting called.

[bbatsov]

I've added some IL tests - hopefully I got those right. First contributions as always the hardest... 😅

[vzarytovskii]

I've added some IL tests - hopefully I got those right. First contributions as always the hardest... 😅

Yeah, those are the ones I meant. However, I do see that for some of them it is calling ToString for some value types (i32 for example), and calls string overload for the Write(Line)

[brianrourkeboll]

However, I do see that for some of them it is calling ToString for some value types (i32 for example), and calls string overload for the Write(Line)

That's inherent to the approach taken in this PR (calling string on the input and passing it to Console.WriteLine), no?

We could delegate to the appropriate overload of Console.WriteLine at compile time by using static optimizations for common types (like the string function itself does).

[vzarytovskii]

However, I do see that for some of them it is calling ToString for some value types (i32 for example), and calls string overload for the Write(Line)

That's inherent to the approach taken in this PR (calling string on the input and passing it to Console.WriteLine), no?

Yes, I forgot to look at the implementation tbh.

We could delegate to the appropriate overload of Console.WriteLine at compile time by using static optimizations for common types (like the string function itself does).

We probably should, jit might lift some allocations to stack, but we shouldn't rely on it.

[bbatsov]

I think I'll need some more pointers about the next step, as I'm not quite sure how to proceed from here.

[Happypig375]

@bbatsov consider looking at the implementation for the string function and use a similar syntax for Console.WriteLine overloads.

[bbatsov]

I've added static optimizations for string, char, and bool — these types are culture-independent, so we can call the corresponding TextWriter.Write/WriteLine overload directly, bypassing the string operator entirely.

For numeric types (int, float, decimal, etc.), we must continue going through the string operator to ensure InvariantCulture formatting. TextWriter.Write(int) internally calls value.ToString(FormatProvider), and Console.Out.FormatProvider is CultureInfo.CurrentCulture — so delegating directly would break InvariantCulture consistency for negative numbers and floating-point values in some locales.

The IL tests now verify:

• int/float → ToString(string, IFormatProvider) with InvariantCulture + Write(string)
• string → direct Write(string) (no null check overhead)
• char → direct Write(char)
• bool → direct Write(bool)

I hope I got those right. I never thought a couple of print functions could be so involved. 😅