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":

letprint(value:'T)= Console.Out.Write(string value)letprintln(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

You can open this PR in browser to add release notes: open in github.dev

---

✅ Found changes and release notes in following paths:

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

[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. 😅

[bbatsov]

In case that matters - I rebased the PR on top of the current main. Also - should the release notes be in the file for F# 10 or 11? The CI checks seems to look for them in 11.

[T-Gro]

Release notes for 11 (it will now be more stable for requiring 11 for about half a year).

[bbatsov]

Just moved the release notes to (hopefully) the right place.

[esbenbjerre]

The RFC describes print and printn functions but this PR uses println - I thought it was decided to go with printn to be consistent with printfn, no?
Looks great otherwise - is there anything else blocking this?

[bbatsov]

Renamed println → printn to match the RFC and stay consistent with printfn. Folded it into the existing commits and rebased on latest main, so there's no stray println left in the history. CompiledName stays PrintValueLine (same as printfn → PrintFormatLine), so the surface area baselines are untouched. Thanks @esbenbjerre@charlesroddie@T-Gro for the nudge.

[T-Gro]

Just run fantomas now and it is ready to go 👍

[bbatsov]

Build's green now. The formatting failure wasn't actually about the rename - it was the static-optimization when clauses in print/printn, which Fantomas 7.0.1 can't format. That's the same limitation that already keeps prim-types.fs, printf.fs and friends in .fantomasignore (they use the same when ^T : ... = ... construct), so I added this file there too.

[bbatsov]

🤞 I got everything right this time around. If this gets merged I'm never using printfn again. 😂

[charlesroddie]

Only thing left is to click the merge button @T-Gro@vzarytovskii ?

[bbatsov]

Seems this now needs one more review to be merged. I hope @vzarytovskii can help with this.

[bbatsov]

🎉

I'm really glad we managed to drive this to the finish line! Thanks, everyone! 🙇