-
Notifications
You must be signed in to change notification settings - Fork 116
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
refactor: keep same api as v0.14.0 for SplitFirst/SplitLast #271
Conversation
Not worth breaking this function, and it saves us some pain with updating downstream deps
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one specific comment.
if c.Empty() { | ||
return nil | ||
} | ||
return []Component{c} | ||
return []Component{*c} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we make these slices with a higher capacity?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's hard to predict how a user will use this. If they want a higher capacity they should just use the slice of Components directly
util.go
Outdated
} | ||
return m[:len(m)-1], m[len(m)-1] | ||
return m[:len(m)-1], &m[len(m)-1] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks unsafe.
last points to the last element in the slice. So appends to the first bit(the multiaddr) will modify last, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The same argument also applies to SplitFunc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a defensive copy
Perhaps not worth breaking this function, and it saves us some pain with updating downstream deps. For example, drand would not require a backport of this change to work with multiaddr.
The risk of then calling a method on the returned nil pointer is alleviated by changing the Component methods to be pointer receiver (as before) and checking for nil pointers explicitly.
Would also remove these breaking changes: