Skip to content

Enforce Explicit Types and Target Type new #2951

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

Merged
merged 3 commits into from
Jun 24, 2025

Conversation

stefannikolei
Copy link
Contributor

@stefannikolei stefannikolei commented Jun 21, 2025

Prerequisites

  • I have written a descriptive pull-request title
  • I have verified that there are no overlapping pull-requests open
  • I have verified that I am following the existing coding patterns and practice as demonstrated in the repository. These follow strict Stylecop rules 👮.
  • I have provided test coverage for my change (where applicable)

Description

Reworkes #2855 after too Manz conflicts

@stefannikolei
Copy link
Contributor Author

Collection Expression is still a problem..
image
SA1515 enforces a new line before this comment.

Do we wanna enforce Collection Expressions?

I think we have this options
a) Disable SA1515 (StyleCop Analyser seems unmaintened should be probably analysed and looked for alternatives..)
b) Insert the Blank Line
c) #pragma disable

@stefannikolei stefannikolei changed the title Sn/ref/explicit types Enforce Explicit Types and Target Type new Jun 21, 2025
@JimBobSquarePants
Copy link
Member

JimBobSquarePants commented Jun 24, 2025

Collection Expression is still a problem.. image SA1515 enforces a new line before this comment.

Do we wanna enforce Collection Expressions?

I think we have this options a) Disable SA1515 (StyleCop Analyser seems unmaintened should be probably analysed and looked for alternatives..) b) Insert the Blank Line c) #pragma disable

I think, in this case, moving the comment above the declaration would be the correct solution. As to whether we should enforce collection expressions.... I don't know, I like them very much but sometimes they can reduce readabilty.

@stefannikolei
Copy link
Contributor Author

OK Then let's go this way.

This PR is complete from my side. When this one is merged I will open a draft for the Collection Expressions so we have a clear view how it is gonna be for this repo.

Sounds good?

Copy link
Member

@JimBobSquarePants JimBobSquarePants left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for doing this; much better!

@JimBobSquarePants JimBobSquarePants merged commit 8c5c577 into SixLabors:main Jun 24, 2025
8 checks passed
@@ -24,7 +24,7 @@ namespace SixLabors.ImageSharp.ColorProfiles;
/// <param name="l">The l value (lightness) component.</param>
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public Hsl(float h, float s, float l)
: this(new Vector3(h, s, l))
: this(new(h, s, l))
Copy link
Member

@antonfirsov antonfirsov Jun 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JimBobSquarePants I'm late to the party again, but I dislike this particular group of the changes. Now a code reader needs to navigate to the other method definition to see what type is being instantiated here, which makes it harder/slower to read the code. Same for return new(...) and similar expressions which remove type information completely from a given line.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that's a drawback about this. I will create a PR which tackles this. Rider/Resharper has more settings for this and was probably a bit more aggressive. Could you check that branch out and look what VS is doing? #2958

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! #2958 looks good based on the diff, but I can't tell if it's missing something without pulling the code down and review offline.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apologies, I missed this. According to IDE0090 the analyzer should only be flagging when the type is apparent. Is Rider/Resharper buggy?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rider generates a warning at that rule stating that this one is unknown/unsupported.

It has more granular editorconfig settings.

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

Successfully merging this pull request may close these issues.

3 participants