V4 Development: General strategy on how to fill in missing APIs

[danielmarbach]

Describe the feature

I'm currently fiddling around with some performance improvements and for some cases I need to somehow polyfill certain missing APIs or attributes. For example in order to implement overrenting when doing stack allocations it might be beneficial to add SkipsLocalsInit. Another example are missing encoding extension methods that accept ReadOnlySpan.

Several of these cases can be poly filled by adding corresponding attributes or methods into the utils and that might be the teams preferred approach. On the other hand there are libraries like Polyfil or Polysharp that to some extend implement those workarounds already.

In order to proceed forward it would be great if the strategy for the v4 development branch would be documented somewhere. Additionally the team could potentially also set the LangVersion to a reasonable language version that the team wants to allow so that contributors have clear guidelines on what or what not to use.

Use Case

Contributing to v4 development but I guess these questions are anyway something the team on the v4 branch has to have answers for independent of whether someone contributes or not.

Proposed Solution

No response

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

AWS .NET SDK and/or Package version used

v4

Targeted .NET Platform

all

Operating System and version

all

[danielmarbach]

To add an example. Here is a new URL encode method I quickly spiked danielmarbach@81d8586. Already there I'm missing proper GetBytes and GetString overloads for Netstandard that I would have to shim. I don't have SkipLocalsInit and I have discrepancy between TryGetValue and GetValueOrDefault.

[normj]

@danielmarbach Agreed we need to get this documented. We haven't really talked too much about V4 yet other then the blog post announcing the drop in support for .NET Framework 3.5. Not trying to keep it a secret but we are taking care of some internal infrastructure changes right now to support both a V3 and V4. After that I was hoping to be more proactively public about V4. That being said don't let that stop you from contributing to V4. The main thing about V4 is it will be evolutionary not revolutionary so only breaking changes when necessary to make a better product.

To your immediate question about poly fills the SDK is still going to take a hard rule of avoiding taking on external dependencies. The SDK is too low level in most people's applications and dependencies we take can cause collection with versions customers use or we could be forced to make breaking changes due to the dependencies we don't control.

Using pragmas to target newer versions and leaving older versions using stock implementations is perfectly fine in the SDK. I'm not very interested in having pragmas with special implementations in older targets. I don't want to build up code we have to maintain for targets people are moving away from.

[Dreamescaper]

@normj

To your immediate question about poly fills the SDK is still going to take a hard rule of avoiding taking on external dependencies. The SDK is too low level in most people's applications and dependencies we take can cause collection with versions customers use or we could be forced to make breaking changes due to the dependencies we don't control.

Both Polyfil and Polysharp are source-only dependencies, meaning that customers wouldn't even know that SDK uses them.

[danielmarbach]

Absolutely what @Dreamescaper said. Essentially those are development time dependencies and will not be dependencies on the shipped product at all. So the risk here is probably more of a supply chain risk than anything else (which obviously requires considerations I get that)

[normj]

I didn't realize the libraries were source-only dependencies. As you can call I haven't ever tried them before. Let me play around with them to get more familiar with them and then I will come back.