IRC meeting summary for 2017-02-02
- 0.14 RC1 release
- Coding style
0.14 RC1 release
Bitcoin Core 0.14 is scheduled to be released around March 2017. Open pull request aimed for 0.14 are tagged with a 0.14 tag.
RC1 is aimed to be released on 2017-02-06.
BlueMatt thinks #9671 (Fix super-unlikely race) is going to be required for release.
Issue #9027 (Unbounded reorg memory usage) should be pushed to 0.15 as it’s not a regression. It’s slightly worse than it used to be, but not enough that we definitely need to fix it asap.
The importmulti changes can be done after 0.14 or can be disabled for release if it isn’t safe enough in time. It could also be left undocumented, however that would require issue #9491 (Importmulti API is confusing in a way that could lead to funds loss) to be fixed.
- Discuss the importmulti issue on the issue itself (#9491)
Stylistic consistency in the code has some benefits:
- it aids newcomers in their contributions because it is easier for them to make sure their work is okay on styleistic grounds.
- It eases review because the uniformity creates better expectations, however reformating makes looking at the history harder, which harms review.
- Good style choices have, at times, been shown to lower defect rates in software, but there is not a universal opinion on what choices are good.
Since C++11 it’s possible to use an “auto” specifier. It specifies that the type of the variable being declared will automatically be deducted from its initializer.
BlueMatt thinks the use of ‘auto’ makes certain review much harder as he often searches for “everywhere X is used”. Sipa proposes a workaround for this by introducing an incompatible change to the type and recompile so all the places it is used become visible. The discussion started here.
Wumpus advises to document specific cases where the use of ‘auto’ is bad or dangerous.
The advantages of using auto, besides where it replaces a lot text to type, is that you don’t need to change things all over the place when you turn a tuple into a struct or add a wrapper.
Gmaxwell adds another negative side is that auto enables you to write code that acts on a type while having no idea of the type yourself, which is safe 99% of the time and dealy the rest, as in C++ not all operations which are categorically unsafe on a type are actually stopped by typechecking. Although an edge case, it’s something to keep in mind.
Auto is interesting when you have some horrible complex signature, however those are the cases where it’s also more of an issue. Sipa notes best practice for those usecases is to introduce a typedef for it, which also lacks the review concerns from BlueMatt.
- consider the use of ‘auto’ case by case.
|wumpus||Wladimir van der Laan|
This summary was compiled without input from any of the participants in the discussion, so any errors are the fault of the summary author and not the discussion participants.