SRTP's bugs and future plans

languagedesign

#1

Hello fellows, right now this is a thread collecting ideas how to fix overload resolution and other stuff related to STRP’s.


#2

Here’s an example of an issue that shows unexpected resolution in presence of overloads and SRTPs https://github.com/Microsoft/visualfsharp/issues/1287


#3

I want to give an update to the situation:

Don Syme and me worked together on resolving a bug with SRTP’s and discovered that fixing the bug most likely won’t be able without breaking changes in the inference behaviour.

As our proposed fix is in our understanding the correct approach, code which isn’t working anymore needs to be understood so both it’s intention and technical reason can be used for future warnings and maybe even new language suggestions.

With this in mind we want to focus on one of the biggest consumer of the SRTP feature: F#+

The library is going to be integrated as part of the F# compiler test suite to discover new regressions with SRTP’s and also for researching code which breaks with the fix. This also includes understanding whether the fix stops any code which was only possible thanks to oddities in the SRTP behaviour.
Especially the latter is something Don Syme and me want to research to come up with better approaches / language suggestions to allow such code with a more well defined mechanism.

To sum up, the plan for the future will be:

  1. Integrate F#+ as part of the compiler test suite
  2. Investigate which codes breaks due to the proposed fix
  3. Research whether the code could be written differently / Overthink certain SRTP rules if necessary
  4. Implement the new language suggestion locked behind a flag
  5. Continue work on started new SRTP features (like later introduced members visible to SRTP constraints)

PS: Correct me if I’m wrong @dsyme