Why does the SDK guideline define the necessity for sync methods?

Query/Question

https://azuresdkspecs.z5.web.core.windows.net/DotNetSpec.html

Why does the SDK guideline define the necessity of providing sync method overloads? How are you planning to implement those? I hope you are not going to use GetAwaiter().GetResult() but have a clear dedicated synchronous HttpPipeline? But still why is this required at this day of age when Task returning APIs for IO bound domains is the defacto standard?

Why is this not a Bug or a feature Request? A clear explanation of why is this not a bug or a feature request?

Setup (please complete the following information if applicable):

• OS: [e.g. iOS]
• IDE : [e.g. IntelliJ]
• Version of the Library used

Information Checklist Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

• Query Added
• Setup information Added

[j82w]

If the only reason to support synchronous call stacks is to support older existing application would it be better to try to build a library or some other solution as an additional package to convert asynchronous SDK to synchronous? This seems like unnecessary bloat for most users since modern applications are asynchronous. Also by supporting synchronous APIs directly in the SDK users might start building new applications with the sync API. The user will eventually hit scaling/performance issues and have to convert to async. This would also avoid every SDK team from needing to duplicate their entire call stack to support the synchronous calls.

[msftbot[bot]]

Hi, we’re sending this friendly reminder because we haven’t heard back from you in a while. We need more information about this issue to help address it. Please be sure to give us your input within the next 7 days. If we don’t hear back from you within 14 days of this comment the issue will be automatically closed. Thank you!