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

Rename Range to IndexRange #35145

Closed
YohDeadfall opened this Issue Feb 7, 2019 · 13 comments

Comments

Projects
None yet
8 participants
@YohDeadfall
Copy link
Collaborator

commented Feb 7, 2019

There's the Range struct in .NET Core 3 which is in progress. This type represents a range of indexes, but while the design time many people though that it will be a generic thing to store ranges of any types. So probably this demand would be implemented in the future in .NET. For but for now everyone tries to implement it's own range types. In Npgsql we are designing our new implementation of it too (npgsql/npgsql#2314).

Would it be better to rename the type to IndexRange to avoid future name collisions and to give it a more meaningful name?

@jkotas jkotas transferred this issue from dotnet/coreclr Feb 7, 2019

@stephentoub stephentoub added this to the 3.0 milestone Feb 7, 2019

@stephentoub

This comment has been minimized.

Copy link
Member

commented Feb 7, 2019

@YohDeadfall

This comment has been minimized.

Copy link
Collaborator Author

commented Feb 19, 2019

From dotnet/corefxlab#1859 (comment) by @jaredpar:

The language design at this time does not intend to support a generic Range type. Rather we are focusing on concrete types and operator extensibility to support additional ranges.

Even if there is no generic range planned it makes sense to rename the type to prevent further confusion.

@danmosemsft

This comment has been minimized.

Copy link
Member

commented Mar 11, 2019

@terrajobst presumably this needs consideration now before we ship this type. If this won't happen, please close.

@YohDeadfall

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 11, 2019

While doing a research for #35420 about range usage in different languages, I found that something similar exist in F# but called sequences. In F# a sequence is an abbreviation for IEnumerable<T> and it can be constructed via one of two range operators (.. for ranges without step and .. .. for ranges with step).

So there may be introduced confusion too, because this type is shared across all .NET languages and will exist in F#.

References:

@karelz

This comment has been minimized.

Copy link
Member

commented Mar 13, 2019

@terrajobst was it covered in API review?

@terrajobst

This comment has been minimized.

Copy link
Member

commented Mar 13, 2019

I think it might be too late to change the name. The API and language design was in discussion for a long time . Meanwhile, the feature was implemented and the compiler is already binding against these names. We might be able to pull a DCR here but I'm not convinced that there is sufficient data to suggest we need to rename. For starters, whenever we add primitive types there is a very strong desire to have single-word names. This inevitably causes conflicts; there is no good way around this but I don't think we should give fundamental types -- that we expect many people to use -- more complex names to avoid conflicts that will impact only a much smaller group.

That being said, I'll bring it up in the next API review meeting.

@terrajobst

This comment has been minimized.

Copy link
Member

commented Mar 19, 2019

We discussed this today but we feel it's too late to make this change now.

@terrajobst terrajobst closed this Mar 19, 2019

@ghuntley

This comment has been minimized.

Copy link
Member

commented Mar 19, 2019

@roji

This comment has been minimized.

Copy link
Member

commented Mar 19, 2019

Discussion starts 38:40

@YohDeadfall

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 20, 2019

@terrajobst Okay, let it be. Anyway, may I ask you a related question? Due to various reasons like historical, lack of time, etc. there were made not so good decision while growing .NET Framework and .NET Core. For example:

  • non-generic collection which could be replaced by generics (lack of time as Jeffry said);
  • read-only collection interfaces from which read-write collection don't inherit;
  • DateTimeKind which brought a lot of pain (new date and time types don't have that field);
  • whole System.Data which were designed with the SQL client in mind and which doesn't respect other database provider limitations and lacks of generic parameters (maybe DbNull could be removed because of nullable value types and dotnet/csharplang#2194);
  • three task types which could share a common interface;
  • maybe this one too in the future.

I understand that nothing will be changed in the nearest future (say .NET Core 3) because of porting .NET Framework applications to Core and killing the first one, and it's very hard job, but does Microsoft have some thought about breaking backward compatibility and start with a new clean API?

@ghuntley Thanks for posting the link in the Npgsql repo, but it's minor here. There is a primary related issue in CoreFx. See #35420.

@karelz

This comment has been minimized.

Copy link
Member

commented Mar 21, 2019

@YohDeadfall what would be the value (vs. impact on existing applications and libraries and ecosystem) of each of your points?
Personally I don't think the first two and this one will ever happen. I don't have deeper knowledge of the rest.
If any of them would be considered in future, it would be specific decision for the specific proposal / suggestion.

@YohDeadfall

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 22, 2019

@karelz I understand your concerns and agree that it isn't an easy process, but there are a two main point of doing it:

  • Additional points of performance optimizations. Not every method or class can be optimized now because it was designed in the time when some things didn't exist.
  • Clean API surface without duplicating code, less name collisions, removed old code which should be maintained right now. For users it would be helpful too because of less room for mistakes.

In overall it should improve user experience, so I think it's win-win for Microsoft and its customers, but with some pain during migration. See Python for example. They did the same thing. By the way, if I understand correctly one of points of .NET Core is ability to choose which version you want to run. So each service or an application can run using required version of .NET, and there can be a smooth migration process. Did I miss something?

@karelz

This comment has been minimized.

Copy link
Member

commented Apr 9, 2019

Performance is important, but should not go over usability. It is a very fine line to walk. Even adding new APIs is not clearly a win. Everything has to be taken into account (incl. developers' confusion which API to use when/why - applies e.g. to Span overloads).

Clean API surface without duplicating code, less name collisions, removed old code which should be maintained right now. For users it would be helpful too because of less room for mistakes.

It sounds reasonable high-level, but the devil is in the details. In my experience these things are rarely clear win situations. The problem has more dimensions and complexity than usually expected. I would suggest to discuss it on specific examples.

In overall it should improve user experience, so I think it's win-win for Microsoft and its customers, but with some pain during migration.

Migration is part of the story. If the win is small, it does not justify pain. There are also other dimensions - existing guidance and content - think books, Stack Overflow samples, etc.

By the way, if I understand correctly one of points of .NET Core is ability to choose which version you want to run. So each service or an application can run using required version of .NET, and there can be a smooth migration process. Did I miss something?

Technically yes, practically we need to be a bit cautious. If we cannot articulate clear win for a change, we should NOT do it. Don't forget we have to support .NET Standard and library ecosystem which multitargets .NET Framework, .NET Core, Mono and UWP. We cannot start changing fundamental APIs. API changes are best thought as "addition only".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.