Curious as to how much this is used. ARM64 has no support for it, and all modern x64 processors are optimized for 64bit doubles. Also, using 80bit basically eliminates SSE support, which is often a huge hit. Also, if you need the extra precision, it is probably best to use a library like GNU MPFR explicitly.
The context here comes down to depreciating the longdouble.dll Windows library which needs MinGW to compile. The goal being that Racket and the core libraries can be compiled with Mingw64 or MSVC.
As far as I remember, for non-Windows platforms Racket has stopped supporting them for a long time since Racket-on-Chez became the default.
(FWIW, Racket call this type as Extflonums. This page may be helpful: 4.3.5 Extflonums -- extflonum-available? returns false and extfl+ errors with "unsupported".)
This is the only blog post I found, though:
Racket CS is intended to behave the same as the existing Racket implementation with a few exceptions:
no single-precision or extended-precision flonums;
80-bit conflicts with MMX, not SSE. SSE has been the norm for 64-bit since ~2000. FPU/MMX and SSE are different FUs and there is no reason beyond compiler support that they can't be used together.
Even after SSE based 64-bit became the norm (circa ~2000), you still could use MMX and SSE together because they don't conflict. And you could do 80-bit FP from assembler while doing 64-bit FP or SIMD from your compiler.
My vote would be to lose 80-bit. I've been writing software since the mid 1980's, and have yet to encounter a situation where 64-bit floating point was not sufficient.
I would like to see Racket make more use of SIMD for vector/array processing. I may be wrong, but AFAIK, the only thing Racket does with SSE is ordinary floating point.
We should drop support. Chez doesn't support. ARM is increasingly important and doesn't support. The fl2 family of operations exists for users who want more precision. We used them for a while in Herbie and removed support.
I agree that we can stop including longdouble.dll. Although that DLL doesn't really need to be rebuilt ever, so we could keep using the existing build, it's simplest to just drop it.