Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #634 +/- ##
==========================================
- Coverage 88.10% 88.09% -0.02%
==========================================
Files 29 29
Lines 1908 1906 -2
==========================================
- Hits 1681 1679 -2
Misses 227 227 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Why is this not breaking currently? |
|
This package is loading It is because of this type-piracy that it might be better to not depend explicitly on |
|
Is it breaking to drop Offset Arrays as a dependency now? |
There was a problem hiding this comment.
Pull Request Overview
This PR removes a custom padded_similar function and replaces its usage with Julia's built-in similar function. The change aims to eliminate an explicit dependency on OffsetArrays to facilitate moving OffsetArrays support to a package extension in future releases.
- Removes the
padded_similarfunction definition that handled both regular arrays and offset arrays - Replaces the call to
padded_similar(TC, indspad)withsimilar(Array{TC}, indspad)
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
| indsA = axes(A) | ||
| indspad = padded_axes(indsA, it) | ||
| coefs = padded_similar(TC, indspad) | ||
| coefs = similar(Array{TC}, indspad) |
There was a problem hiding this comment.
The replacement similar(Array{TC}, indspad) may not be functionally equivalent to the original padded_similar(TC, indspad). The original function returned OffsetArray{TC}(undef, inds) for non-OneTo indices, but similar(Array{TC}, indspad) will always return a regular Array type regardless of the index type. This could break functionality when indspad contains offset indices.
There was a problem hiding this comment.
Is that actually a problem based on how coefs is used?
There was a problem hiding this comment.
Well Copilot isn't correct here. similar will return an OffsetArray if the package is loaded, so there's no difference here.
|
I'm not familiar with this package to say whether it's breaking. Presumably it will be, as offset axes won't be supported by default if |
These should be functionally equivalent, but this removes an explicit dependency on
OffsetArrays. This change makes it easier to moveOffsetArrayssupport to a package extension in a future breaking release.