I would like to share my thoughts

[RioMcBoo]

I'm more of a theorist than a practitioner. But by studying various literature on programming, I've gleaned a few so-called "language ideals" to strive for.

I was initially hostile to C# when I first became interested in it 10 years ago. I didn't see enough advantages to use it over C++.

However, after returning to it 10 years later and seeing how it's evolving, I became interested, and I'm programming in it as a hobby. Therefore, everything I'll describe below may not be a problem at all, but in my opinion, it's important when considering "where we're going."

The point is that a programming language, as such, serves several basic functions:

1) code readability and simplicity in expressing intent;
2) protection from potential basic errors that a user might inadvertently make due to not being able to keep the entire architecture of the application they're developing in mind;
3) Allows you to create your own abstractions on top of existing base ones to protect your code from errors that users might inadvertently make due to their inability to keep the entire architecture of the application they're developing in mind;
4) Collect as much data as possible from the code that can be determined at the compilation level, so that at this stage you can replace references and entities (objects) with direct method calls and addresses, instead of creating real entities with internal state and reflection (which wastes computer resources).

So, after a bit of practice, I started asking myself questions about why and how this works in C#.

[RioMcBoo]

Question 1. Concerning protecting users from basic errors. I found that C# went against the core principles of programming, which can be summed up as "implicit conversions cannot be performed if they result in data loss." I understand that the user can override implicit conversion operators and create chaos in their code, but they are limited by the fact that if the language defines two or more possible implicit conversions at once, it requires explicitly specifying which type to cast to. Nevertheless, all languages ​​generally strictly define the behavior of base types and prohibit data loss. But I discovered that C# has its own strange logic and behavior with implicit conversions, and here's an example. Moreover, I agree with any rules as long as they work the same everywhere (they can be memorized and worked with, just like when we multiply an integer by a floating-point number—we immediately understand that the result will be a floating-point number with a loss of precision).

This also includes another problem I discovered. It turns out that C#, unlike C++, allows you to convert integers to floating-point or decimal numbers implicitly, allowing for data loss. (I'm not sure about decimal, since it takes up 16 bytes and I don't use it at all.)

But that's barely half the problem. It turns out that C# uses some kind of internal code optimization, which, even in debug mode, deceives the user and thinks that long and double are the same and compares them as two equal numbers (I'm not sure about the entire range of values; perhaps there is a margin of error at which it considers the numbers equal to each other, but nevertheless, when converting long -> double -> long, an optimization occurs that makes C# think that no conversion took place.) I learned about this by accident when I simply wanted to show with an example that double cannot store the entire range of integers from the long type. (Not to mention float).

[CyrusNajmabadi]

This also includes another problem I discovered. It turns out that C#, unlike C++, allows you to convert integers to floating-point or decimal numbers implicitly, allowing for data loss.

We mention this explicitly in the spec/docs. See, for example, https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/conversions#1023-implicit-numeric-conversions:

Conversions from int, uint, long or ulong to float and from long or ulong to double may cause a loss of precision, but will never cause a loss of magnitude. The other implicit numeric conversions never lose any information.

We accept this as reasonably pragmatic behavior that balances friction vs capability.

[RioMcBoo]

Conversions from int, uint, long or ulong to float and from long or ulong to double may cause a loss of precision, but will never cause a loss of magnitude. The other implicit numeric conversions never lose any information.

We accept this as reasonably pragmatic behavior that balances friction vs capability.

Just follow the link and read my last reply to find how it would be in alternative way.

And, tell me please what is the precision and magnitude in an integer type? If you convert from double to integer - this works, but not otherwise

[CyrusNajmabadi]

Just follow the link and read my last reply to find how it would be in alternative way.

Your link doesn't change what i said at all.

And, tell me please what is the precision and magnitude in an integer type? I

Let's explain with the concrete example using long to double conversion.

Magnitude refers to the "size" or "scale" of the number - roughly speaking, how many digits it has, or what power of 10 it's near.

When converting long to double:

A long value of 9,223,372,036,854,775,807 (around 9 × 10^18)
Converts to a double that's still around 9 × 10^18

The converted value might not be exactly right, but it's still in the same ballpark - it's still "billions of billions," not suddenly 127 or -1 or some completely different scale.

Contrast this with long to byte:

long n = 123456789012;  // 123 billion
byte b = (byte)n;       // wraps to 212

Here you've lost magnitude entirely - you went from hundreds of billions down to hundreds. The number is completely unrelated.

Precision refers to how many significant digits you can represent accurately.

A long has exact precision for all integers in its range. Every value from -2^63 to 2^63-1 is distinct.
A double has only 53 bits of precision in its mantissa. This means:

For integers up to 2^53 (about 9 quadrillion), every value is exactly representable
Beyond 2^53, you start "skipping" integers - not every integer can be represented

Concrete example:

long x = 9007199254740993;  // This is 2^53 + 1
double d = x;                // Implicit conversion
Console.WriteLine(d);        // Outputs: 9007199254740992

The double can't represent the exact value 9007199254740993, so it rounds to the nearest representable value, which is 9007199254740992. We've lost precision (the exact value is wrong), but we haven't lost magnitude (it's still around 9 × 10^15).

Tanner is def the expert here. I may have gotten some tiny details wrong. But hopefully this helps explain the behavior. Most importantly though, we recognize this and we have accepted (and documented) that it should work this way. Primarily because we think it's acceptable to lose precision while maintaining magnitude.

You are free to disagree. We do not presume that any of our defaults are correct for all users. If you disagree you can trivially write an analyzer to block this sort of thing and require that you make this conversion explicit not implicit.

[tannergooding]

Tanner is def the expert here. I may have gotten some tiny details wrong

This all looks accurate to me, at least at a 3am glance ;)

The only thing I'd note is in the below, it should instead be "every integer is exactly representable". It's a minor nuance, but avoids people going "but what about 0.3" and other fractional data that can't be exactly represented:

For integers up to 2^53 (about 9 quadrillion), every value is exactly representable

There's a personal nit about the use of the word magnitude, I think its the incorrect word to use in the spec due to what that word means in mathematics and the IEEE 754 floating-point spec already. However, that's largely irrelevant to the conversation here and getting the point across 😆

[CyrusNajmabadi]

Thanks tanner!

[RioMcBoo]

Question 2. This is working with enumerations. Without referring to how enumerations work in C#, we can say that they are simply a named range of values ​​that we expect to see in a variable. Therefore, any enumeration is simply syntactic sugar, and the variable remains the same variable, the same type. This can be related to point 4 about the compilation phase.

However, if we consider the possibility of inferring the enumeration name associated with its value, simply replacing methods and references won't work. We need to create an entity that stores the names of all values ​​and the methods for working with these values. I even tried creating something myself. And I would have created it if I hadn't encountered some language limitations, which would have required using reflection and so on, meaning a performance penalty. And most importantly, I would have had to manually create this entity each time, along with all its unique methods for a specific type under a wrapper.

Nevertheless, I know of several working examples of metaprogramming in C#, where the language itself creates entities and methods. For example, the Records type.

But instead of automatically creating a static type at compile time and getting a powerful helper in the form of an enumeration, C#, for some reason, has created and is reluctant to create anything new other than the Enum class. Not only can this type not be used for arithmetic generics, it's also subject to constant boxing/unboxing, and it lacks basic methods for working with [flags] (which it supposedly works with). Examples of this discussion can also be found here.

[CyrusNajmabadi]

but could you give us generic Enum

Requests for generic enums should go to the runtime. Enums are provided by them.

no easy math in generics, no extensions because of no generics.

You can petition the runtime to add support for generic math on enums. That said, i believe when they've looked at this before, they're not very amenable to it due to the cost of adding that metadata to all enum types.

[RioMcBoo]

For Example:

enum MyCloths<byte> : IBinaryInteger<byte> //, Interface implemented hiddenly automatically 
{
   Shorts,
   T-shirt,
}

bool static operator HasFlag<T>(this T left, T right) where: T is IBinaryInteger<T>
{
return left & right == right;
}

And no problem in 99,999999%

[CyrusNajmabadi]

This is sore and suffering...

@RioMcBoo please follow the advice in #9853 (reply in thread)

If you have issues with the runtime and enums, file issues for them. If you want specific language changes (things that must be done in C# itself) then please open a discussion specifically on the changes you'd like to see. Discussing here isn't valuable as the discussion is already heavily cluttered with many different topics and tangents.

We are very amenable to improving the language, including with enums. But please read the rules here: https://github.com/dotnet/csharplang/#discussions

Specifically:

Discussions that are short and stay on topic are much more likely to be read.

To make discussions easier to navigate and benefit from, please observe a few rules of thumb:

Discussion should be relevant to C# language design. If they are not, they will be summarily closed.

Choose a descriptive topic that clearly communicates the scope of discussion.

Stick to the topic of the discussion. If a comment is tangential, or goes into detail on a subtopic, start a new discussion and link back.

"i would like to share my thoughts" is not a good, descriptive, topic for suggestions on changes you want to see in the language related to enums. You might want to browse through many of the discussions here first to see if the ideas have already been raised, and to see how a successful discussion is crafted.

[CyrusNajmabadi]

//, Interface implemented hiddenly automatically

As mentioned,

You can petition the runtime to add support for generic math on enums. That said, i believe when they've looked at this before, they're not very amenable to it due to the cost of adding that metadata to all enum types.

These things are not free. This adds metadata and runtime costs to all enums, regardless of whether they need this support or not.

Furthermore, the shape isn't really appropriate. With that shape, if you perform binary operations on an enum, you'll now end up with an instance of the underlying type, not the enum type, which is likely not what someone would want.

[CyrusNajmabadi]

And no problem in 99,999999%

That is not the case. You've now added more jit cost, more metadata cost, and what to all enums in all programs. I would ask that you please read the responses thoroughly, and examine discussions on this topic in the past in both runtime and C#. There is interest in these things, but there are real world concerns that cannot be ignored.

I absolutely understand that for your needs, those costs may not be a concern, however (as i mentioned earlier) C#/.Net has a massive ecosystem of users across many different domains. What may be an acceptable cost for you may be a deal breaker for others. We have to consider the entirely of that ecosystem when making decisions.

[RioMcBoo]

Question 3. While studying collections and the cases where they can be used, I discovered that almost all C++ collections, in one way or another, operate internally on the principle of trees or linked lists.

I've thought long and hard about when linked lists are truly useful. The seemingly obvious advantage of fast insertion and deletion is negligible in those cases (in most cases) where we first need to figure out exactly where to insert or delete an element, which means performing a sequential search along the chain and finding a pointer to the desired link. However, most everyday operations require fast searches, quickly reviewing all values, and so on. I think linked lists are useful in a very narrow range of tasks or when working under resource constraints. At first, I didn't understand why C# practically doesn't have collections based on linked lists. Now I understand, because the cost of allocating new memory or copying all the values ​​when expanding the list isn't that great, but the lightweight nature and fast iteration come with it.

But something else surprised me. Even C# doesn't have collections based on binary search. Or rather, there are one or two, but they're very slow and unproductive.

I tried creating my own list with binary search, which I think is the fastest sorting method (if you simply dump all the values ​​into a new binary list). And it didn't even go badly. But in the end, I came to the conclusion that C#'s SortedList works like a collection with a Key-Value pair—and that seemed right. I even considered rewriting my code to match SortedList. But I realized I had another problem, and it's called "I can't ensure Key immutability." This applies to class-based types, as well as structures that store reference data types. After all, even restricting the "Key" type to the IClonable interface doesn't guarantee the user will implement it correctly. It turns out that the user is solely responsible for keeping the fields used for comparison immutable. This is fraught with hidden errors, and this isn't really a high-level programming issue.

As I understand it, int GetHashCode() also doesn't fully protect against modification, even though the hash itself is stored in a base structure type, which ensures its immutability and the ability to be perfectly cloned without errors. If there are collisions in hash tables (of which C# is full), a comparison still occurs, and I don't understand how hash tables are protected against this.

But most importantly, I realized that C# is sorely lacking ways to constrain its structures during declaration and creation to ensure the functionality of its own data types and collections and protect itself from errors.

Therefore, I believe the language needs some basic interfaces that will be implemented automatically through metaprogramming at compile time to ensure 100% implementation of these interfaces.

For example, I want to create an immutable key. I'll have to implement the IClonable interface to store a copy of the key, ensuring its immutability (which is critical for binary sorting). A user might implement it incorrectly by simply leaving a reference to a reference data type that will be modified. The error won't be immediately apparent and could have disastrous consequences, and this is without even mentioning the loss of productivity. Therefore, I'll have to use ReadOnly data types. But you probably know that in C#, readonly can only ensure immutability for value types. Working with reference types is also easy to make a mistake if you don't understand how it works.

Nevertheless, I'd really like to see a collection based on my collection, or an optimization of the existing SortedList.

In my opinion, binary collections can replace small hash tables (as people often use them to store and access even small collections by key due to lack of alternatives), and when sorting, ordering, and fast access are needed simultaneously, they're even better than hashes and trees.

You can create hybrid collections based on binary lists. I think many agree that binary lists are slow to edit, but check out my solution; you might find it elegant.

[CyrusNajmabadi]

At first, I didn't understand why C# practically doesn't have collections based on linked lists

A couple of things. First, the language doesn't care at all about how collections are implemented. That's the choice if the API.

Second, the .net runtime (which delivers the base class libraries) does have collections that use linked lists or trees as the backing store.

So it's unclear where you got this idea of C#/.net from. Cheers!

[tannergooding]

I discovered that almost all C++ collections,

This isn't accurate. The primary (most broadly used) collection types like std::vector don't do this for example, it is guaranteed to be a contiguous collection of items and is logically similar to List<T> in .NET, just with the nuance of a special bit-backing optimization for bool existing.

C# practically doesn't have collections based on linked lists

.NET explicitly does, it provides LinkedList<T>, as one example. It also uses linked lists (in some variety) to implement Dictionary<TKey, TValue>, there are various tree like structures used for some of the immutable collection types, the Roslyn ASTs are a form of linked list, etc.

What is "correct" is dependent on the domain and scenario, with .NET providing all the same general types that standard libraries of languages like C++ provide, plus often a few extra.

which I think is the fastest sorting method

This is dependent on many factors. Binary searching/sorting "can" be fast, particularly for already sorted data. It is often slower for others, which is why so many such algorithms exist.

Even C# doesn't have collections based on binary search

.NET provides several APIs and functions for doing binary searches and for generally sorting or searching data. List<T>.BinarySearch is a trivial example that is on the primary collection type.

[CyrusNajmabadi]

But most importantly, I realized that C# is sorely lacking ways to constrain its structures during declaration and creation to ensure the functionality of its own data types and collections and protect itself from errors.

"protect itself from errors" is entirely dependent on the domain. We do not aim to make all domain errors expressible in the language itself. We strike a balance in terms of what we think should be pulled into the language, and what should be in the realm of libraries.

Every user will have different feelings on where this line is. Some feel that hte rules we have in the language should be in libraries instead. Some believe the opposite. We consider the cases and make determinations accordingly.

Therefore, I believe the language needs some basic interfaces that will be implemented automatically through metaprogramming at compile time to ensure 100% implementation of these interfaces.

You are welcome to propose specific language changes you would like. We will consider accordingly.

Please do not use this discussion for this. It is already sprawling, and covering a vast number of different topics. If you have specific changes you would like to see, start individual discussions on them so they can be evaluated, the community can weigh in, and we can plan accordingly.

Nevertheless, I'd really like to see a collection based on my collection, or an optimization of the existing SortedList.

Thse are requests for the runtime. The language does not care. A good way to make this distinction in your head going forward:

1. are you asking for something that other .net languages (of which there are many) would benefit from? If fso, it's not C#/Roslyn.
2. is this specific to C#, and requires some actual change to the language itself to accomplish it. If so, it goes here.

Since you're just asking for a new/updated collection api, it falls into teh first bucket. It would be something any .net lang could use, and is unrelated to C#.

In my opinion, binary collections can replace small hash tables (as people often use them to store and access even small collections by key due to lack of alternatives), and when sorting, ordering, and fast access are needed simultaneously, they're even better than hashes and trees.

That opinion seems fine for your domain. You can discuss with runtime what they feel is best for the entire ecosystem to supply directly in the bcl, or which is better provided as an external library.

[tannergooding]

The general set of thoughts shared here seem to have a lot of misinformation and general misunderstanding. Many of the points raised are either personal opinion or are trivially disproven with a simple web search.

For example, just doing C# collection binary search in any of the major search providers not only gives examples of how to do this via the current AI integrations, such as Copilot on Bing or AI Overviews on Google, but also links to things like the docs for List<T>.BinarySearch.

Likewise there is a large number of incorrect statements about how other languages work, particularly C++, and conflating of different parts of the various ecosystems such as what is language vs libraries vs runtime.

I'd suggest doing some deeper research on these topics and potentially engaging in general public forums around the languages to get such questions answered, rather than making presumptions about how things operate.

[CyrusNajmabadi]

I'd suggest doing some deeper research on these topics and potentially engaging in general public forums around the languages to get such questions answered, rather than making presumptions about how things operate.

To this point, i recommend you come talk to the team over at:

C# Lang Design
Runtime
Roslyn

The first is for discussions about the language itself. The rules of it. The reasons why we did things a certain way. Things we're considering for the future.

The second is for the runtime. This includes the actual runtime which executes code, including things like jit/GC. It also includes the libraries.

The last is for Roslyn. The mainline compiler implementation of the C# language, owned and maintained by Microsoft. Discussions about how C# becomes IL, or information about quirks/deviations from the language spec go there.

[CyrusNajmabadi]

I also agree with Tanner that there's just a large amount of incorrect information here. Both about C#/Roslyn/.Net-Runtime, and about C++ as well. The channels above are places where you can discuss things with the experts and help address several of this misinterpretations and misunderstandings.

Finally, i would suggestion potentially restarting this discussion after you've done that. Having distinct discussions for each question/area you are concerned about. Having an uber discussion with everything intermixed is just cluttered, and makes it difficult to tease things apart.

I'm considering locking this discussion. But i'll leave open a little bit to see if it can get on track.

[RioMcBoo]

I wrote my thoughts, gave you samples, you know how it works under cabine, and you in charge how your product works.

I don't care about what would you do with this information. I wanted to be heard because sometimes working with C# looks like you don't care about it.

I am glad that you aware about all these mentioned "features".

I yes, i don't know a lot about specific things, it were thought as a sound after reading some books.

Just don't try answer me immediately, i don't want to take all these as resolved just right now.

[CyrusNajmabadi]

I wanted to be heard because sometimes working with C# looks like you don't care about it.

I'm not sure where you got this impression, but i'm sorry if you feel that that's the case. We engage with huge amounts of the community in many ways, including just chatting with them personally on pretty much any topic.

The purpose of our responses was to show you that we both do care about thse topics, and that we've given them a lot of though.

i don't know a lot about specific things,

That's entirely fine. But my personal recommendation in this case is to just go directly to the source. It will help avoid a lot of misunderstandings and incorrect information that you appear to have stumbled across. We're happy to help. We just think there are better avenues to approach this by. Thanks :)

i don't want to take all these as resolved.

There may be a language barrier. I'm not sure i understand what this is trying to say.

Def come chat on discord. We're happy to shed more light on all these areas you're interested in. We have a wide variety of experts there. Including those who know C# and C++ very well (including me :)). It will likely be very helpful with clearing things up for you and allowing you to come to a more informed and accurate opinion on these topics.

Thanks!

[CyrusNajmabadi]

I have locked this conversation due to be too vague, full of inaccuracies, and because the specific, actionable, requests that are being made are not being followed. @RioMcBoo please listen to #9853 (reply in thread) and #9853 (reply in thread).

Opening further discussions is fine. Just keep them focused and specific on topics. Note: if something is a request for the runtime, we would prefer you open it there (and we'll move discussions htere that clearly belong there). If something is more of a hybrid (needs work on both sides) it's fine to have here.