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

Use getOrElse in NonEmptyList#last #3168

Merged
merged 1 commit into from
Mar 22, 2020
Merged

Conversation

PeterPerhac
Copy link
Contributor

seems like someone re-implemented Option's getOrElse inside NonEmptyList. Delegate to Option#getOrElse instead

seems like someone re-implemented Option's `getOrElse` inside NonEmptyList. Delegate to Option#getOrElse instead
@codecov-io
Copy link

codecov-io commented Nov 20, 2019

Codecov Report

Merging #3168 into master will decrease coverage by <.01%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #3168      +/-   ##
==========================================
- Coverage   93.04%   93.04%   -0.01%     
==========================================
  Files         376      376              
  Lines        7374     7373       -1     
  Branches      209      209              
==========================================
- Hits         6861     6860       -1     
  Misses        513      513
Flag Coverage Δ
#scala_version_212 93.34% <100%> (-0.01%) ⬇️
#scala_version_213 90.63% <100%> (-0.01%) ⬇️
Impacted Files Coverage Δ
core/src/main/scala/cats/data/NonEmptyList.scala 98.7% <100%> (-0.01%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 55c48a8...c2e2785. Read the comment docs.

@joroKr21
Copy link
Member

It could be an optimization.

@travisbrown
Copy link
Contributor

I'm not sure this is the reason for the original implementation, but getOrElse takes a Function0 argument, and before Scala 2.12 that meant that the pattern matching version was one allocation lighter. In this case now it's just an extra synthetic method and my guess is the two are probably close to the same.

Neither of those versions are going to be anywhere close to if (tail.isEmpty) head else tail.last, which actually does still avoid an allocation on 2.12+, but I don't think it matters much here.

@djspiewak
Copy link
Member

This is somewhat defensible as an optimization, but as @travisbrown pointed out, both of them are quite slow compared to the if/else equivalent. I don't see any problem with the simplification.

@larsrh larsrh merged commit 9475120 into typelevel:master Mar 22, 2020
@travisbrown travisbrown added this to the 2.2.0-M1 milestone Mar 30, 2020
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.

6 participants