Improve error position/range for arrow functions with expression body

[OliverJAsh]

Improve error position/range for arrow functions with expression body

[Andarist]

The mentioned discussion happened here. I don't mind this change if the team likes it. My main problem with it is that it's a pretty short error span but OTOH you can end up with even single-character error spans anyway so that concern can be ignored.

It should be OK - especially with the adjusted error message like the one proposed by @DanielRosenwasser .

I'm pretty sure I'll this change, as I've also mentioned in that same comment 😉 :

I prefer to highlight smaller spans over huge ones

[RyanCavanaugh]

Seems reasonable. If a return type annotation exists, we can put it there

// Arrow function with expression body
// Today
const g1: () => number = () => pipe(1, add(1), identity);
//                             ~~~~~~~~~~~~~~~~~~~~~~~~~
// Proposed
const g2: () => number = () => pipe(1, add(1), identity);
//                          ~~
// Or (?)
const g3 = (): number => pipe(1, add(1), identity);
//             ~~~~~~

Aside: Try to guess where the error span is in this code! 🫠

const p: () => string = (): number => 32;

[DanielRosenwasser]

I kind of like moving it to the return type itself, but either way I feel like we should adjust the error message in these cases if possible. Something like

This function returns the type 'unknown' which is not assignable to its declared type 'number'.

[fatcerberus]

I recall that I once suggested putting the error span on the => for this exact reason, by analogy to the return in the block function. IIRC @Andarist objected.