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

Creating a Range indexer #101

Open
gregsdennis opened this issue Apr 30, 2024 · 0 comments
Open

Creating a Range indexer #101

gregsdennis opened this issue Apr 30, 2024 · 0 comments

Comments

@gregsdennis
Copy link

I have a .Net library project that dual-targets netstandard2.0 and net8.0. On one of my classes I'd like to have an indexer that takes a Range object, which, for the netstandard2.0 target, is thankfully generated by PolySharp.

In order to have my indexer be public, I have to set PolySharpUsePublicAccessibilityForGeneratedTypes to true, to expose Range.

However, this creates a problem when consumed by any target framework that already includes Range, which is literally everything Core 3.0 and up.

Here's a solution that replicates the issue: PolySharpReplication.zip.

I can't (and don't want to require my users to) add a disambuating using statement because (1) the generated Range and the built-in Range share the same namespace and (2) the name Range isn't actually used so a using wouldn't do anything anyway.

I could add netcoreapp3.0 and/or all of the other targets to my library, but that has a follow-on effect because I have multiple other libraries that depend on this one. So I'd need to also add all of those targets to all of those projects as well. That kinda defeats the purpose of targeting netstandard2.0 in the first place. I'd prefer not to do that.

Is there a way for me to add the indexer without raising the conflict in consuming applications? I assume there must be a way to do this, otherwise it seems like making the generated types public serves no purpose.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant