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

C# - support for op_Assign #62835

Closed
c-ohle opened this issue Jul 21, 2022 · 0 comments
Closed

C# - support for op_Assign #62835

c-ohle opened this issue Jul 21, 2022 · 0 comments
Labels
Area-Language Design Concept-API This issue involves adding, removing, clarification, or modification of an API. Feature Request untriaged Issues and PRs which have not yet been triaged by a lead

Comments

@c-ohle
Copy link

c-ohle commented Jul 21, 2022

C# - support for op_Assign

To improve and to keep the .NET 7 API simple, in discussion with dotnet devs, we came back to an old problem.
I know the papers and specs, but I would suggest reconsidering the decision regarding an assign-operator or a similiar solution.

To implement numeric types in C# with numeric- and conversion operators is great - so long the type is simple, has fixed size and don’t need normalization.

But if it starts with, for example, arbitrary size types, there is a problem.

Let’s take as example - the well known type System.Numerics.BigInteger.
The goal is to get from computations an immutable readonly struct object what is not a problem if we have expressions like a = b + c;
But in practice we have expressions like: x = a * b + c * d;
The compiler generates a sequence of operator calls from this but the operator has no hint if this is for a final result or for a intermediate result only. The operator has therfore always to deliver a final result that involves the memory allocation for the data and normalization.
This is despite the fact that the internal BigInteger.Builder is in use and could high efficiently process the intermediate results.
This leads to lot of memory garbage and performance impact too.

The net/numerics team is planning at this point to make the, so far internal, BigInteger.Builder public to give the user at least a chance to write more efficent code.
I have the same problem with a Rational arithmetics solution.
There are so many other cases, starting by simple string building up to classes that would get a chance to reset her chaches in a determinated way.

For the end user it means having to deal with builder classes and leads to less readable, error prone code. For the runtime more extra classes, special handling and less efficient memory management.

All of this could be avoided if there were a unary operator op_Assign, called once if defined before a real assignment to a var or any other target occurs.

 [SpecialNameAttribute]
 public static BigInteger op_Assign(BigInteger value) => value; // default does nothing  

It should be easy to extend the compiler for this convention without any logical problems.
Only some code lines in the compiler could save so much redundant code and improve the performance.

It would help to make C# better, faster, memory efficient, readable and secure.

@c-ohle c-ohle added Concept-API This issue involves adding, removing, clarification, or modification of an API. Feature Request labels Jul 21, 2022
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Language Design untriaged Issues and PRs which have not yet been triaged by a lead labels Jul 21, 2022
@dotnet dotnet locked and limited conversation to collaborators Jul 21, 2022
@CyrusNajmabadi CyrusNajmabadi converted this issue into a discussion Jul 21, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Area-Language Design Concept-API This issue involves adding, removing, clarification, or modification of an API. Feature Request untriaged Issues and PRs which have not yet been triaged by a lead
Projects
None yet
Development

No branches or pull requests

1 participant