Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[API Proposal]: StrongBox.Create #105400

Open
colejohnson66 opened this issue Jul 24, 2024 · 3 comments
Open

[API Proposal]: StrongBox.Create #105400

colejohnson66 opened this issue Jul 24, 2024 · 3 comments
Labels
api-suggestion Early API idea and discussion, it is NOT ready for implementation area-System.Runtime.CompilerServices needs-further-triage Issue has been initially triaged, but needs deeper consideration or reconsideration
Milestone

Comments

@colejohnson66
Copy link

colejohnson66 commented Jul 24, 2024

Background and motivation

Many generic types have static, non-generic, classes with a Create helper method. This allows the compiler to infer the generic argument. StrongBox<T> does not.

Arguably, since StrongBox<T> is in System.Runtime.CompilerServices, it should not be used by user code. However, it is a useful type in multithreaded code as it allows atomic updates (by nature of being heap allocated), and avoids boxing/unboxing overhead; only an allocation. The unboxing overhead can be eliminated with Unsafe.Unbox, but, as the name suggests, it's an unsafe API.

API Proposal

namespace System.Runtime.CompilerServices;

public static class StrongBox
{
    public static StrongBox<T> Create<T>(T value);
}

API Usage

Old code:

Interlocked.Exchange(ref _currentValue, new StrongBox<decimal>(newValue));

New code:

Interlocked.Exchange(ref _currentValue, StrongBox.Create(newValue));

Sure, target-typed new could be used on the old code, but some people disable that lint if the target type is not evident.

Alternative Designs

No response

Risks

No response

@colejohnson66 colejohnson66 added the api-suggestion Early API idea and discussion, it is NOT ready for implementation label Jul 24, 2024
@dotnet-issue-labeler dotnet-issue-labeler bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Jul 24, 2024
@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Jul 24, 2024
@vcsjones vcsjones added area-System.Runtime.CompilerServices and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Jul 24, 2024
Copy link
Contributor

Tagging subscribers to this area: @dotnet/area-system-runtime-compilerservices
See info in area-owners.md if you want to be subscribed.

@stephentoub stephentoub added this to the Future milestone Jul 24, 2024
@ericstj ericstj added needs-further-triage Issue has been initially triaged, but needs deeper consideration or reconsideration and removed untriaged New issue has not been triaged by the area owner labels Jul 24, 2024
@julealgon
Copy link

Why do we keep adding factory methods like this to the public API instead of just adding generic type inference to constructors?

Seems like such a low-hanging fruit at this point that would increase consistency in the language with not-so-much effort (considering there is already generic type inference in methods), and would finally remove the need for this whole "class" of dumbh factory methods that were added just to circumvent the lack of generic type inference in constructors, like KeyValuePair.Create, Tuple.Create (back then when we still used reference tuples...), etc.

Factory methods should only be needed when they add valuable semantics to the code IMHO (e.g. TimeSpan.FromSeconds). This is not one of those cases.

@KalleOlaviNiemitalo
Copy link

adding generic type inference to constructors

There is a proposal at dotnet/csharplang#281.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api-suggestion Early API idea and discussion, it is NOT ready for implementation area-System.Runtime.CompilerServices needs-further-triage Issue has been initially triaged, but needs deeper consideration or reconsideration
Projects
None yet
Development

No branches or pull requests

6 participants