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. Cheers, Brian > Ehsan > > -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
