Proposal: Default-allow C++YY features on time basis

[Peter Kasting]

(Proposing here based on positive signals on Slack discussion)

I propose that we default-allow features from new C++ versions at some time threshold after we declare those versions "supported" in Chrome.  At that point, we would remove the "allowed" and "TBD" sections of chromium-cpp.appspot.com for that version, and leave only the "blocked" section; anything not blocked is implicitly allowed.

The goal of this is to avoid having this page grow forever, and to minimize the delta between "what C++11 developers in the wild use" and "what C++ developers in Chrome use".

For reference, the formal C++11 support declaration ( https://groups.google.com/a/chromium.org/d/msg/chromium-dev/xMscQuYBwyc/_mvdlqKFEHgJ ) was Sept. 23, 2014.  I think we would be fine with moving C++11 features to default-allowed today.

The formal C++14 support declaration looks to be https://groups.google.com/a/chromium.org/forum/?utm_medium=email&utm_source=footer#!msg/cxx/ow7hmdDm4yw/zQWXGBC8BQAJ , which was August 15, 2017.  I could be convinced either way on whether we're ready to blanket-allow C++14 features.

I propose a time threshold of two years from when we first announce codebase-wide support.  That would enable C++11 by default today, but not C++14 for another six months.

PK

[Dirk Pranke]

Aren't we still significantly held back here by the NaCl toolchains? I know thakis@ has been working on that, but I don't know how far he's gotten or what the end stage might be.

-- Dirk

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To post to this group, send email to c...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAAHOzFBToTS4RXLGaYQ%2Bu6xtDysRzbDj84Y_oSNq7vO9PCb25Q%40mail.gmail.com.

[Peter Kasting]

On Thu, Feb 28, 2019 at 1:54 PM Dirk Pranke <dpr...@google.com> wrote:

Aren't we still significantly held back here by the NaCl toolchains? I know thakis@ has been working on that, but I don't know how far he's gotten or what the end stage might be.

I thought that was relevant to the question of when we can begin allowing C++17 features.

My proposal is about, for language versions we already allow in Chromium, when after we allow them (note: not "after they're standardized") do we default-allow them.

PK

[Nico Weber]

For c++11 this and c++14 this sounds fine. For C++17, we're still blocked by reality, like dpranke mentions.

When having slack discussions, please always summarize them instead of just saying "as discussed on slack", both for posterity and for people who aren't on slack.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAEoffTB_v7vOUmyMsOGssqTWPM_DCexfC0eu4jo10e7HVr-VtQ%40mail.gmail.com.

[Peter Kasting]

On Thu, Feb 28, 2019 at 1:57 PM Nico Weber <tha...@chromium.org> wrote:

For c++11 this and c++14 this sounds fine. For C++17, we're still blocked by reality, like dpranke mentions.

At the risk of restating things due to messages crossing in transit: the clock would not start when ISO ratifies a version, but when we declare it as globally usable in Chromium.  Since we haven't done that with C++17 yet, there'd be no timeframe on C++17 yet.

If we were to declare tomorrow that C++17 is allowed in Chromium, this proposal would default-allow its features in early 2021.

When having slack discussions, please always summarize them instead of just saying "as discussed on slack", both for posterity and for people who aren't on slack.

Point well-taken, but I intended this thread to stand alone; there wasn't significant discussion on slack other than me checking I wasn't obviously-mistaken before proposing this.

PK

[Yuri Wiitala]

We need to be careful: There are parts of the STL covered by existing constructs in base (e.g., <chrono> versus base::Time/TimeTicks, threading, atomics, etc.). While it might be good to consider migrating to the new STL features for better long-term platform support/compatibility/code health, I don't think it'd be good for 2+ solutions to the same problems to become sprinkled throughout our code base.

On Thu, Feb 28, 2019 at 1:57 PM Nico Weber <tha...@chromium.org> wrote:

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAMGbLiGLD5%2B_z5UCf97oeHkKXQ7-WLUykNzpvNS1bjSQDmxfmw%40mail.gmail.com.

[Nico Weber]

On Thu, Feb 28, 2019 at 5:05 PM Yuri Wiitala <m...@chromium.org> wrote:

We need to be careful: There are parts of the STL covered by existing constructs in base (e.g., <chrono> versus base::Time/TimeTicks, threading, atomics, etc.). While it might be good to consider migrating to the new STL features for better long-term platform support/compatibility/code health, I don't think it'd be good for 2+ solutions to the same problems to become sprinkled throughout our code base.

<chrono> is already listed as banned at http://chromium-cpp.appspot.com . I guess the argument is if we haven't something banned within 4 years, we probably won't.

[Yuri Wiitala]

Sounds good.

(FWIW, at some point I'd like to review the <chrono> ban. I believe we only banned it so we wouldn't have two different time libraries in-use.)

[Peter Kasting]

On Thu, Feb 28, 2019 at 2:19 PM Yuri Wiitala <m...@chromium.org> wrote:

(FWIW, at some point I'd like to review the <chrono> ban. I believe we only banned it so we wouldn't have two different time libraries in-use.)

+1; I'd love to migrate from Chrome-specific to standards-based solutions over time if the only reason to prefer the Chrome one is inertia.  That said, I haven't looked at the <chrono> facilities, so I don't know what the tradeoffs on this specific one would be.

On Thu, Feb 28, 2019 at 2:09 PM Nico Weber <tha...@chromium.org> wrote:

<chrono> is already listed as banned at http://chromium-cpp.appspot.com . I guess the argument is if we haven't something banned within 4 years, we probably won't.

Correct.  Banned features wouldn't be unbanned.

PK

[Daniel Cheng]

I think I'm OK with this, for the sake of shortening the (already very long documentation). Two thoughts though:

- sometimes, there are tips attached to the current 'allow' sections: is it worth keeping those at all?

- rather than default allowing, I think we should just force a discussion on the remaining TBD items and explicitly allow/ban them rather than leaving them in limbo. The TBD sections are pretty small so I don't think this would be an undue burden.

Daniel

--

You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To post to this group, send email to c...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAAHOzFAOLRZDFRwaeQsL2e4p%3DGaknONNJGOya%2BuZ3w_N2_Bhrw%40mail.gmail.com.

[Peter Kasting]

My opinions:

On Thu, Feb 28, 2019 at 2:32 PM Daniel Cheng <dch...@chromium.org> wrote:

- sometimes, there are tips attached to the current 'allow' sections: is it worth keeping those at all?

IMO no; if there's something here that everyone _needs_ to know, it should be in a different doc anyway, e.g. dos-and-donts.

 

- rather than default allowing, I think we should just force a discussion on the remaining TBD items and explicitly allow/ban them rather than leaving them in limbo. The TBD sections are pretty small so I don't think this would be an undue burden.

I was hoping to avoid this but I guess if the discussion is "is there any reason to ban any of these? no? OK" then it's not much worse.

PK

[Kyle Charbonneau]

The proposal seems like a good idea in general but +1 to forcing (hopefully quick) discussion and a go/no go decision on remaining TBD features. For example std::weak_ptr is still in the list of C+11 TBD features and probably shouldn't be allowed since std::shared_ptr is banned.

--

You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To post to this group, send email to c...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAAHOzFD589113fNr%2B9FsUa2S5rf7V1JDi%2BfFLp-pToo__1ajfA%40mail.gmail.com.

[Peter Kasting]

Summarizing feedback thus far:

* General agreement

* No specific comments on timeframe (so I assume the "two years from Chromium-side support" timeframe is OK)

* Some desire to explicitly discuss all remaining TBD issues when we default-allow

I'd like to wait until next week before considering this decided, to give people sufficient time to respond.  But if we were to decide the above, I think these are the next actions:

* Start a separate thread on what to do with all remaining C++11 TBD items.  I plan to do this regardless, since we're probably in a position to make general calls here.

* Modify the C++11/14 page to reference this policy, and add relevant dates somewhere (when we started allowing C++YY features and when we will default-allow them).  I can be responsible for this too.

PK

[Jeremy Roman]

Most of the remaining "to be discussed" itme sare things that wouldn't be particularly useful in Chromium regardless, but I'd be okay with allowing them regardless to shrink the size of what people need to know.

I think probably the most interesting one is the user-defined literals, like operator""s, which have been discouraged in the past.

--

You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To post to this group, send email to c...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAAHOzFDAd2JbPfAfmX0TDEMou1tHwZ1%2B3gLLgb7bnNHOvR_PZw%40mail.gmail.com.

[Peter Kasting]

On Fri, Mar 1, 2019 at 10:56 AM Peter Kasting <pkas...@google.com> wrote:

I'd like to wait until next week before considering this decided, to give people sufficient time to respond.

It's been close to a week, so I consider this proposal approved.

I think these are the next actions:

* Start a separate thread on what to do with all remaining C++11 TBD items.  I plan to do this regardless, since we're probably in a position to make general calls here.

* Modify the C++11/14 page to reference this policy, and add relevant dates somewhere (when we started allowing C++YY features and when we will default-allow them).  I can be responsible for this too.

I will try to take action on these.  My stack of work is growing rather tall (I still have outstanding styleguide change proposals from December I need to implement) so if someone else feels passionate about moving forward in the meantime feel free.

PK 

[Peter Kasting]

On Fri, Mar 1, 2019 at 10:56 AM Peter Kasting <pkas...@google.com> wrote:

* Modify the C++11/14 page to reference this policy, and add relevant dates somewhere (when we started allowing C++YY features and when we will default-allow them).  I can be responsible for this too.

This is now landed.  C++11 is default-allowed.  We should have a conversation about default-allowing C++14 around August 15, as that will be the two-year mark for that.

Given that that's less than two months away, I'll start a thread on the remaining C++14 TBD features; it will probably take me at least a couple of months to put its recommendations into action :)

PK

[Peter Kasting]

On Thu, Feb 28, 2019 at 2:19 PM Yuri Wiitala <m...@chromium.org> wrote:

(FWIW, at some point I'd like to review the <chrono> ban. I believe we only banned it so we wouldn't have two different time libraries in-use.)

I filed https://bugs.chromium.org/p/chromium/issues/detail?id=976306 to re-evaluate this.

PK 

[Claudio DeSouza]

I'm gonna reply in the ticket later on, but I don't think that std::chrono would be a good option. First, std::chrono doesn't provide any checked numerics, last time I've checked. The other problem I have with std::chrono is that it ends up having different units of time and duration codified in the the type. What I've seen that tends to happen is that people end up putting seconds in one API, and then you have another values in another source being passed in millisecs, and then you might hit conversion problems.

I particularly prefer the simplicity of base::Time/TimeDelta.

- Claudio.