On Fri, Aug 2, 2013 at 9:11 PM, Brian Smith <br...@briansmith.org> wrote:
> On Sat, Aug 3, 2013 at 12:50 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com>wrote: > >> On 2013-08-02 4:49 PM, Brian Smith wrote: >> >>> That sounds reasonable to me. So, based on that then, let's get back to >>> my >>> original question that motivated the discussion of the policy: If we add >>> std::move, std::forward, and std::unique_ptr to STLPort for Android and >>> B2G, can we start using std::move, std::forward, and std::unique_ptr >>> throughout Gecko? >>> >> >> Yes, if they're available in all of our environments, I don't see why >> not. What we want to be careful with is how the STLport changes would work >> (we don't want to make builds fail if you just grab an Android NDK). >> > > I am not quite sure what you mean. Here is the workflow that I was > envisioning for solving this problem: > > 1. Add std::move, std::forward, and std::unique_ptr to STLPort > (backporting them from STLPort's git master, with as few changes as > possible). > 2. Write a patch that changes something in Gecko to use std::move, > std::forward, and std::unique_ptr. > 3. Push that patch to try (try: -b o -p all -u all -t none). > 4. If all the builds build, and all the tests pass, then ask for review. > 5. After r+, land on mozilla-inbound. If all the builds build, and all the > tests pass, then anybody/everybody is free to use std::move, std::forward, > and std::unique_ptr. > > To me, this is the most (only?) reasonable way to decide when enough > configurations support a language feature/library we are considering using. > > I wrote that post with the incorrect assumption that our STLport copy is not easily modifiable (thanks glandium for correcting me on that!). With the light of this new information, if somebody is willing to do the above work, then r=me! :-) Cheers, Ehsan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
