<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 11, 2014 at 12:41 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">----- Original Message -----<br>
> From: "Richard Smith" <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>><br>
> To: "Marshall Clow" <<a href="mailto:mclow.lists@gmail.com">mclow.lists@gmail.com</a>>, "Eric Fiselier" <<a href="mailto:eric@efcs.ca">eric@efcs.ca</a>>, "cfe commits" <<a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a>><br>
> Sent: Tuesday, November 11, 2014 2:05:21 PM<br>
> Subject: [PATCH] [libc++] reject <chrono> literals that can't be represented<br>
><br>
><br>
><br>
> [time.duration.literals]p3 says:<br>
><br>
><br>
> "If any of these suffixes are applied to an integer literal and the<br>
> resulting chrono::duration value cannot be represented in the result<br>
> type because of overflow, the program is ill-formed."<br>
><br>
><br>
> That's unimplementable in standard C++, but implementable with Clang<br>
> using the enable_if attribute. This patch also rejects<br>
><br>
><br>
> (void) operator""ns(0x8000000000000000ull);<br>
><br>
><br>
> ... and it's not entirely clear whether that's permissible, but this<br>
> is the best we can do at the moment (and I think it's a good thing<br>
> to reject the above code).<br>
><br>
><br>
> Thoughts?<br>
<br>
</span>Are there other places in <chrono> that require a language extension? Requiring a language extension to implement <chrono> seems like a bug in the specification. I'd vote for an LWG issue.<br></blockquote><div><br></div><div>There already is one: <a href="http://cplusplus.github.io/LWG/lwg-active.html#2383">http://cplusplus.github.io/LWG/lwg-active.html#2383</a> -- my preferred fix for that is to simply make it "no diagnostic required", so that we can continue to diagnose this and other implementations can do something worse =) [... and then, eventually, to improve the core language such that this doesn't require an extension, and remove the "no diagnostic required" again.]</div></div></div></div>