Why do the Microsoft guidelines for F# not recommend returning a tuple from code that will be used by C#?

According to the F# guidelines, tuples as a return type from F# are not recommended for code that will be consumed from C#.

Avoid using tuples as return values.

There seems to be good compatibility for tuples between the two languages. Especially in the newer versions. So, I don't quite understand this recommendation. I'm planning to return a struct instead to avoid whatever the harm is that these guidelines must have in mind.

The explanation they give is vague.
>they will most often not provide the ideal and expected API for .NET developers.

What does this mean exactly? What pitfalls can I expect to run into if I ignore this and return tuples anyway?

I think the direct answer to your question is that most C# and .NET API's don't return tuples. Originally, this was because older versions of C# didn't support tuples, but now it is an established pattern, for better or worse. The F# guideline simply follows the principle of least surprise.

For example, consider Dictionary.TryGetValue:

public bool TryGetValue (TKey key, out TValue value);

F# automatically converts this to TKey -> (bool * TValue), but the fact remains that the tuple return type is not expected in C#.

So, if you're the consumer of the API, then of course you should define it the way you want now. But if this is a public API that will be consumed by typical C# developers, I would strongly consider following the established pattern, even if it is uglier.

That said, tuple return types might (and probably should) become more common in C# and .NET over time. If so, I expect the F# design guideline will eventually be updated as well.