<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 25, 2018, at 3:12 PM, James Y Knight <<a href="mailto:jyknight@google.com" class="">jyknight@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, May 25, 2018 at 5:30 PM JF Bastien <<a href="mailto:jfbastien@apple.com" class="">jfbastien@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On May 25, 2018, at 2:23 PM, James Y Knight <<a href="mailto:jyknight@google.com" target="_blank" class="">jyknight@google.com</a>> wrote:</div><br class="m_-939798776431736792Apple-interchange-newline"><div class=""><div dir="ltr" class="">My own employer doesn't make ABI stability promises for that code, and thus is fine with changing the value anytime it feels like. That's not a generically viable strategy for a value provided by the standard library.<div class=""><div class=""><br class=""></div><div class="">Additionally, before I sent that email, I looked at a number of the uses, and it appeared as though a great many could be easily modified to use a runtime-determined alignment.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">That would be useful feedback on the paper… prior to it getting into C++17. The committee’s POV voting the paper in was that having a constexpr value was something we wanted, and so that’s what we have. At this point in time I’d like to focus on implementing C++17 as it is, and / or filing DRs as required.</div></div></div></blockquote><div class=""><br class=""></div><div style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial" class="">Sure. I'm not on the committee. Even if I was, I certainly don't know that I would have identified the problem...</div><div style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial" class=""><br class=""></div><div style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial" class="">But now that it has been identified, there's a choice of what to do. And not implementing the function (and presumably filing a DR saying so) is seeming like a pretty reasonable option.</div></div></div>
</div></blockquote></div><div class=""><br class=""></div>The committee discussed ABI issues (Jacksonville 2016) and decided that they’d rather have them than have a proliferation of #define SOMETHING 64. That discussion occurred with Google folks in the room, it might be higher bandwidth to consult with them? The notes are unfortunately quite sparse for that discussion.<div class=""><br class=""><div class="">The libc++ community shouldn't decline to implement a feature without bringing concrete feedback to the committee. Without such feedback, I’d like to move forward with an implementation plan, because we should offer full C++17 support regardless of our distaste for specific features. I’ve received good feedback on the thread so far, I’m happy to leave the discussion open for a bit, talk to committee people next week in Rapperswil, and unless feedback goes the committee’s way I’d like to pursue an implementation. Does this sound fair?</div></div></body></html>