C# 8 - System.Index #2148
Comments
|
Is the project .net core, .net standard or .net framework? |
|
@Korporal You should target .NET Core 3.0 in order to make |
|
@Korporal If you don't want to target notecoreapp3.0, another option is to copy and implement the API surface area of |
|
Why isn't this a .Net standard package instead of .Net Core one? |
|
@popcatalin81 It is being added to .NET Standard 2.1. https://blogs.msdn.microsoft.com/dotnet/2018/11/12/building-c-8-0/
From memory, which is more or less accurate, but I don't have references: .NET Standard packages like System.ValueTuple conflict with adding the types in-box for .NET Core 3.0. Moving types in-box has caused no end of tooling bugs and headaches for the team. They want it in-box for C# 3.0 because they don't want to add an entire separate package just to hold these couple of types. |
|
I asked @terrajobst if they plan to create a nuget package exposing
|
|
Well I had little time to explore yet, but I just created a 2019 console app (seems to target .Net Core 2.1 by default and no other .Net Core version seems to be present). Anyway I found (on nuget) a package named
|
|
I do think that the syntax that was settled on for this is poor and the lack of symmetry when accessing the "first" element and "last" element is horrible. I wonder if these would have been better:
then add support for this (while still supporting
along with 0 always referring to lowest indexed element and highest indexed element depending on whether There may be good reasons why the team did it they way they did, but the lack of symmetry makes no sense to me and will no doubt lead to subtle bugs where code is using both kinds of subscripts (perhaps calculating those subscripts) to fiddle with arrays and the developer simply forgot that 0 is first and ^1 is last! As I said elsewhere the index/subscript could have been defined as either the +ve offset from the "first" element or -ve offset from the "last" element. As it stands now ^X means "negative offset X from last element + 1". Is it too late to change this? |
When you start with an incorrect assumption any conclusion will be unreliable.
Those same developers also had to learn that
It's not a question of time, it's a question of justification. One person vehemently disliking something on the Internet is far from a reason for the team to reverse design decisions that came out of numerous design meetings and prototypes. |
@HaloFour - Understood. But can anyone explain what advantages the chosen approach has over my suggested one? I'd truly like to understand the reasoning here. Thanks. |
Complexity. You are suggesting adding two syntaxes, both of which people have to learn, and both of which would be easy to confuse, instead of just one. Instead of just remembering that ^1 points to the last element, they've got to remember which one of >1 and <1 points to the last element. |
Except that I find it hard to accept that the tokens GT or LT when found within Just watch, once this is full released and available to all for production code you're going to see articles and blogs decrying this design. |
The onus would be on you to demonstrate why your suggestion is considerably better. I'd argue that
|
I'm not arguing that Prior to |
|
Anyway I guess nobody's in a position to review the decision, its cast in stone - so be it! |
This is true of literally every language decision made by the C# team. If they didn't design features out of fear that someone somewhere would disagree loudly they'd literally never design anything.
The symmetry of
It's certainly up for review, nothing is cast in stone until the feature ships. The |
|
To me current symmetry is logical rather than mathematical . The thing is, accessing array is mostly based on math not logic. Due to this i foresee that subtracting or adding by one will be quite common due to this discrepancy while one of the minor motivations for this feature is to eliminate such bothersome quirks in as much places as humanly possible. E. g. imagine substracting equal amount of elements from start and end. With current implementation you MUST add by one on end and only end otherwise at best u get out of bounds exception (when substracting 0 elements) and at worst subtle bugs because end is off by one (when substracting more than 0 elements) |
|
The primary motivation is to support slicing, in which case the math works pretty well: var array = new int[] { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
var slice = array[2..^2]; // { 3, 4, 5, 6, 7 }And that's exactly how this works with languages that use negative indexing: >>> list = (1, 2, 3, 4, 5, 6, 7, 8, 9)
>>> list[2:-2]
(3, 4, 5, 6, 7) |
Yes. That is understood. As mentioned several times already, these alternatives were considered, debated, and decided upon based on a wealth of information and cases that demonstrated to the LDM that the current approach is preferable. This was also done with a strong look at the ecosystem out there and how this has worked out elsewhere. Also, as noted several times already: nothing about this design is preventing complimentary indexing/ranging proposals from happening in the future. We picked this design knowing that it would be great for many cases, and intuitive for many, but also not great for some cases. That was going to happen as long as we only allowed a single indexing/ranging approach to start with. The intent here is to have support for the most common and most valuable style, and then see in hte future if it's necessary to provide direct language support for hte less valuable style. -- If you don't want to wait, you can easily add your own |
To me, the current approach is far more intuitive and consistent. It also fits with so many other languages out there. So it's much more advantageous to go with the current POR. |
I totally agree, besides : there is inconsistency between hat Index value in isolated vs Range context. |
how so? in both cases they should be making a System.Index instance in the same manner. |
Well: Index i1 = 3; |
|
This has already been explained. Indexes refer to the position between the elements and don't carry an implied directionality. So when you use an index as the end of a range it is exclusive of the next element after that index. This behavior is consistent with other languages that support ranges and slicing with negative indexes: >>> list = (0, 1, 2, 3, 4, 5, 6, 7, 8)
>>> list[-2]
7
>>> list[3:-2]
(3, 4, 5, 6) |
|
@xCyborg There's no inconsistency there. In both cases i2 is the |
|
I fail to see the significance of "This behavior is consistent with other languages", sure these can serve as a basis, an impetus but C# is it's own language and striving to make it adopt or mimic other languages when there are potential improvements to be had by deviating from them strikes me as a backward thinking. The disregard for symmetry is a mistake in my opinion and the coupling of inclusivity/exclusivity with the way "other languages do it" is not innovative. I really believe that this is going to become seen as a badly implemented capability in years to come, please reconsider, clear the whiteboard and start again. |
Other languages serve as the precedent for how any given feature may be designed. When that design is repeated many times over by completely different teams for completely different languages it speaks to the validity of that design. This model fits well within C#, with the exception that C# cannot flip to negative indexing due to compatibility constraints. It doesn't remotely matter what operator is decided upon here, even if the team decided to drop
This design does not disregard symmetry. The symmetry has been explained countless times already. You have this model of how indexing and slicing works in your head which is not congruent with reality.
You're welcome to your opinion, but reality seems to disagree with you. You not liking something does not make it bad design. |
The current design is felt to be the improved design. This was based on several investigations into the pros/cons of inclusive vs exclusive ranges. In practice, exclusive worked out far nicer and cleaner. As i've also mentioned, nothing about hte current design precludes adding inclusive ranges in the future. however, that assessment will be done at a later point to see if it's really necessary or not. The belief is that exclusive is best to have first, and inclusive can be added later if appropriate.
Being 'innovative' is a non-goal.
The alternatives came with more problems in more cases. The cases have already been enumerated and assessed. No new data has appeared to change any thinking here. |
What disregard for symmetry? |
|
Here are the basic concepts involved:
Devising a symmetrical notation this is a key step, forget "other languages". int array[] = {A,B,C,D,E,F,G,H,I};// Directionality: var X = array[->2]; // X becomes C, backward compatibility means that [->n] is the same as [n].
var X = array[2<-]; // X becomes G.
var X = array[2->]; // X becomes D.
var X = array[<-2]; // X becomes F.// Inclusivity/Exclusivity var inclusive_slice = array[->2..2<-]; // yields: C, D, E, F and G.
var exclusive_slice = array[2->..<-2]; // yields: D,E and F.The suggested operators We can then (intuitively) write: // element 2 from the left including that element - through to - element 3 from the right excluding that element. var some_slice = array[->2..<-3]; // yields: C, D and E. |
@YairHalberstadt - Perhaps but they implicitly supported and today defend the design else we'd surely see their objections expressed here would we not? Never forget the adage "The only thing necessary for the triumph of evil is that good men should do nothing." |
|
Be warned, several regulars here have presented that in their opinion the current design is not consistent. When someone else presents a logical argument as to why it is consistent these individuals react with hostility because their opinion is questioned. |
|
After finding the point between elements naturally described by I see pros and cons to both. No matter which one you pick, you will have to do by-one corrections in a large set of scenarios. I'm not sure which set is larger, but don't be mistaken and think that one of these choices makes off-by-one go away. Also, each way of thinking about it has a powerful mnemonic that will keep you on the right track once this is part of the language and you have to deal which whichever way it is. For the language design team's current choice:
If they change their minds:
I suspect I'll be doing less by-one math with the team's current choice because that's what I gather that their own conclusions were (from what I've read). But either way, I know I'll be able to emphasize the most useful mindset and make the most of it. |
|
Another way to look at it which has been buried:
|
|
If you want to understand our decision-making process on making Range open on the end, you should probably read through the language design notes, especially https://github.com/dotnet/csharplang/blob/72a4daa8532e191858f9f887f4c8d280ec006bb4/meetings/2018/LDM-2018-02-14.md |
@jnm2 - I think the diagram is fundamentally flawed. The integers should sit beneath the cells not the left hand boundary lines, it's the cells (the individual bytes of the byte addressable memory) that are numbered not the implied "lines" between them. |
Effectively it would be the same thing. 5 and ^1 would still index the same element, and both 6 and ^0 would be out of range. |
@HaloFour - But the diagram is flawed and does not correctly represent the problem, as soon as we begin to tolerate an inaccuracy like this it's effects begin to contaminate the solution. |
The diagram is flawed for you. This conversation has happened numerous times now. It's your opinion and it's been heard. But it hasn't been accepted by others. Without a sufficient argument as to why it's more appropraite to see things your way, nothing is going to change here. |
@CyrusNajmabadi - The diagram is flawed period because it numbers the bondaries between cells rather than the cells, no wonder you have trouble understanding when people express objections here.
Are you referring to my opinion about the diagram or the implementation of this index feature? please express yourself accurately if you want to engage in a meaningful technical discussion with me. If you are referring to my views on the implementation then you must be corrected when you assert "It's your opinion and it's been heard. But it hasn't been accepted by others." because even a cursory reading of this issue will show you there are several other people expressing criticisms of how this has been implemented, if you took the trouble to remain objective you'd have noticed this rather than emotionally focusing only on what I say. |
You are stating what it does, not why it is flawed. Others (including myself) do not feel there is any flaw with this sort of representation of the data/logic involved. Indeed, this is how i've been taught and have taught others. It's a very sensible way of understanding ranged operations. For example, when reading a segment of an array, one often is given a starting position and a length. These representations make it very clear waht's happening. The approach that has hte numbers under the slots makes it a lot less clear. Are reads happenign past that point or starting at that point? What does a 0 read length mean if the index selects the whole item? etc. etc.
yes. Your opinion has been heard. It is not agreed with. I'm not sure what you want or expect at this point. Continually harping that you don't like this formalization, while not providing adequate justification, won't get you anywhere. |
I have no trouble understanding. I'm simply stating that your objection has been heard and understood. But that it has also been rejected. The formalization around this has been discussed at length and the pros and cons of it are well understood (especially in relation to the formalization you want). The options were considered and this was felt to be the best approach with full knowledge of all the pros/cons that have since been listed and repeated ad-nauseam. If you don't have anything further to add to the discussion, then simply reiterating that you don't like this formalization and prefer your own, won't get anywhere. -- Note: one thing i did to help out here was to try to use both forms. I did a bunch of work using these alternative approaches working with strings, arrays, file buffers, and several Roslyn data types. By far, the easiest and most intuitive to wrap my head around was the This investigation was also done by several people working with the Range/Index proposal. And it was their great work at actually investigating many domains that helped push nearly the entire LDM (possibly the entire LDM, but i don't really recall at this point) to feel that this form was the better of the two to have by default. |
|
@Korporal Saying the diagram is flawed is begging the question. Maybe it's flawed, if the only way to see things is from a single point of view. The diagram is really good at making the C# team's point of view more intuitive. It's coming across as though you've prejudged the issue and aren't honestly trying to see things from any other point of view. Which is fine, but everyone can sense that you're doing this and practically speaking it's not a convincing maneuver. Neither is combativeness or aggressive choice of words. You may feel they are justified, but even if they are they're working directly against your ability to make a difference, so you decide. |
How can saying the diagram is flawed be begging a question? it's either an accurate depiction of cells and how they're numbered or it isn't, why the reluctance to see the obvious here? If you think a sloppy inaccurate diagram is a sound basis upon which to have a technical discussion then that's fine but I don't work that way.
You say all that just because I regard the diagram to be poor? Then you claim to know what "everyone" is able to "sense" whatever that means! There is no aggression in anything I've posted and I resent you saying otherwise, I disagree on several points with respect to this language feature and as I've just said to someone else I am far from being alone in my criticisms. Please stick to the subject and lets have less strawman posts please. |
You're using your premise to support yourself. But your premise has not been established as being true. It's just a claim on your part. |
To many people here, it's accurate. It's certainly accurate to me, and it's a long established way of thinking about how data is laid out and how indexing and ranges work. It's not like this suddenly popped into existence in this thread.
Begging the question again.
Your disagreement has been heard and evaluated. It was assessed against the other arguments made for the feature as is, along with the empirical evidence about the pros/cons of all the possible options present. It was rejected as providing a less intuitive and understandable model, as well as providing a system that was less easy to use in practice across a wide set of APIs. Absent anything new you can add to help support your argument, nothing about your dislike of the existing POR will change anything. |
|
@Korporal wrote:
The primary limitation of a forum like this is that we have only the written text to interpret. It's a low bandwidth medium. We don't get any additional information from tone of voice, body posture, pace of delivery, facial expression, etc. Add in the fact that different people use the English language in markedly different ways, and it becomes really easy for miscommunication to occur. Hugh, I'm totally willing to believe that you read your words and don't see them as aggressive. Sitting here, on my Saturday morning, most likely halfway around the world from you - because New Zealand is halfway around the world from most everywhere ... you do come across to me across as aggressive. Very much so. That said, I have no doubt that we'd have a great deal of fun debating language design issues over a quiet drink or two, should the opportunity occur. |
|
@Korporal What am I supposed to do with anything you just said? I'm trying to reach out and find middle ground, and you've just taken the opportunity to be rude to me again. Instead of giving an argument, you're sticking to flat contradictions and calling my example sloppy and inaccurate. What would you do if someone replied to everything you said by directly contradicting it, claiming to see a straw man in your argument, and finding a few degrading things to say about you? I'm at a loss. The most reasonable thing I can think of right now, after this final appeal to your humanity, is for me to stop participating in this thread. I mean, what else can I do at this point? You win the stubbornness game, congrats! Nothing has been accomplished. |
The important thing to realize is that you have the ability to affect how others read your words. I've certainly not meant to be aggressive in the past, but it's been read that way by others. That's on me when, on the whole, that is the interpretation of many have come to the same interpretation. In this case, you've come across extremely aggressive. You seem to have flat out been unwilling to come to any sort of understanding of positions different from your own, and you seem to have rejected the idea that your position has been considered but was overruled based on a careful analysis of hte information as well as empirical studies of hte ecosystem. Because you have been unwilling to try to reach any sort of common ground, and because you seem to just flat out reject different points of view, you come across extremely aggressive. You may not intend that. But it's certainly how it's been coming across to me for nearly your entire conduct in this thread. |
@theunrepentantgeek - Please quote me then, don't paraphrase - is this request too something you'd regard as aggressive? Bevan you accuse me of being aggressive yet fail to actually quote an example of such from one of my posts. Perhaps you regard the act of disagreeing and arguing one's case as being aggressive... Anyway I have work to do and the pettiness I'm seeing here is almost juvenile, have fun guys. |
That's an example of aggressiveness, and not being willing to work toward a common ground or understanding. Here are other examples:
Honestly, 'aggressive' is putting it mildly. You're just not behaving in a manner that makes anyone want to converse with you. |
|
@CyrusNajmabadi - You clearly don't know what aggression is Cyrus, you must be of a rather delicate constitution if my words cause you that much angst. Now here's an idea rather than repeatedly whining about my posts here and the effrontery you perceive when someone disagrees with you and is unimpressed with your responses, why not simply stick to the subject at hand. Here's my take 1) The diagram is sloppy and that needs to be said and 2) the way this language feature has been implemented will go down in history as a poor design, of that I'm sure. If people can't even depict the mechanism accurately in diagrams how can we expect the ensuing designs to be sound? |
This is another aggressive and unnecessary statement.
Because your behavior and attitude makes it so that people do not want to converse with you on this topic. If you are unwilling to do anything about that, then no progress can be made at all since any relevant parties will simply no longer respond to you.
Yes, as stated before, your opinion here has been gathered, it just isn't something that is agreed with.
Thanks for letting us know. That's a risk people are willing to take.
The mechanism seems easy to depict in diagrams. You happen to not like the diagram, but that doesn't mean it's not simple to represent and explain. |
|
Yes, everyone will be incredibly confused when C# happens to work the same way as every other language. |
It's helpful to review the definition of the term (you chose to use) "aggressiveness" "Aggressiveness is rarely malicious or violent. Instead, the word connotes assertiveness and drive—a more figurative aggression. It is more of an attitude, and it may even be viewed as a positive character attribute in the workplace or on a sports field, for instance. Aggression involves behaviors that would not be considered acceptable in these settings." [emphasis mine] From here. so thank you for the compliment. I'm done in this thread now. |
Every point about your position has already been addressed. You yourself have admitted it simply comes down to opinion about where you land on the right way to interpret things (i.e. |
Thanks. I think removal from the thread will definitely help keep things more civil and on topic. I appreciate you seeing that and being willing to bow out. |
|
I think the original question has been answered and the rational of why we chose the current design has been linked, so I'm closing this issue. |
I'm playing with VS 2019 and building a project with C# 8, however the use of
^is hampered because the compiler cant findSystem.Index. I have no idea where that is and it doesn't seem to be a nuget package. So am I able to use^in VS 2019 yet or not?The text was updated successfully, but these errors were encountered: