On Mon, Mar 17, 2025 at 11:21 AM Alex Russell <slightly...@chromium.org> wrote: > Why would we change this? We backed the original intent with the usual > conditions: once the concrete is poured, it's done. I'm not inclined to > approve.
That is not, as a general rule, how API owner approval is interpreted, or (as far as I know) intended. It also drastically conflicts with usual practice, which has substantial weight of precedent behind it - while we of course balance the cost of any changes with the benefits, we are generally *open* to changes requested by other implementors, particularly when we're the first to advance an API. In this particular case, the cost is virtually nil - it's a brand new API with minimal usage, and it's a change to a *default* keyword that would rarely be written explicitly anyway. (We only have it at all, rather than just relying on a keyword being absent, due to my own API design preferences, and the fact that it aids us with a small back-compat issue.) The benefit of "make other implementors happier with the API" definitely outweighs the costs here, by any reasonable metric. But even in more controversial/costly cases, I strongly contest the principle you're trying to establish here. We *do* make changes, even ones with compat pain, as part of our unofficial contract with other implementors, to make it more palatable to everyone when we push ahead faster than other implementors are comfortable with or capable of matching. It's always a judgement call, but it leans *much* further toward acceptance than "once Blink API owners approve, the concrete is poured" does. ~TJ -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAWBYDB1ipzqXQ4mWYrYjUXRAwxR0XaCuo6XoHViMnO33-dDbw%40mail.gmail.com.
