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

Tactical solution for explicit generic specialization #884

Closed
degory opened this issue Dec 17, 2021 · 0 comments · Fixed by #885
Closed

Tactical solution for explicit generic specialization #884

degory opened this issue Dec 17, 2021 · 0 comments · Fixed by #885

Comments

@degory
Copy link
Owner

degory commented Dec 17, 2021

Not being able to explicitly specify what specialization of a class or function to reference is quite limiting (see #883)

Need a tactical solution that will allow effective use of Newtonsoft.Json, Moq, FluentValidation etc.

A reasonable simple and not too ugly option would be an explicit specialization operator, that can be unambiguously recognized in the primary expression context where static classes and function groups are parsed.

For example:

Class`[int].function(123)
Class`[string].function("hello")
Class.function`[int](123)
Class.function`[string](123)
degory added a commit that referenced this issue Dec 17, 2021
Enhancements:
- Tactical solution for explicit generic specialization (closes #884) (see #883, #679, #731)

Technical:
- Defeat NuGet cache when bootstrapping locally
- Be more defensive against log stack being corrupted
- Fix issue where diagnostic messages including an instance of the UNDEFINED type could cause an exception
- Update to latest ghul.targets and ghul.test
- When running integration tests locally, use published compiler because installing as local tool requires version bump or NuGet cache clean on every rebuild.
degory added a commit that referenced this issue Dec 17, 2021
Enhancements:
- Tactical solution for explicit generic specialization (closes #884) (see #883, #679, #731)

Technical:
- Defeat NuGet cache when bootstrapping locally
- Be more defensive against log stack being corrupted
- Fix issue where diagnostic messages including an instance of the UNDEFINED type could cause an exception
- Update to latest ghul.targets and ghul.test
- When running integration tests locally, use published compiler because installing as local tool requires version bump or NuGet cache clean on every rebuild.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant