Yep, certainly prefer the std containers if that works for you!
Because there’s so much legacy code out there using the juce ones, we probably won’t deprecate them for a while, and some people do prefer the APIs of the juce ones over the fairly clunky syntax that the std ones use for some common operations.
Is it the kind of thing where you would just add wrappers for the std:: equivalent? I believe you guys did that for the juce::Thread class; it’s just a wrapper for std::thread in Juce5…
Yeah, and I believe they also did it with some other constructs like ScopedPointer wrapping std::unique_ptr. Not a fan of extremely thin JUCE wrappers around std:: objects since their addition in C++11, but as has been said the JUCE APIs are much nicer to read than the std:: ones and there is plenty of legacy code out there that uses it.
There are also certain cases like the JUCE String class where the functionality, usability, and performance are massively improved over their std:: equivalents and will likely never go away.
Idea: a juce_core_legacy (or similarly named) module for JUCE constructs from the pre-C++11 era. This would also encourage users to adopt the std:: versions.
maybe it’s just an xcode thing, but I really don’t like using the std:: methods and classes because there’s no documentation hint that appears when you use the auto-complete. the hints appear for juce classes and methods, tho. it’s very helpful.