----- Original Message ----- > From: "Richard Smith" <[email protected]> > To: "Hal Finkel" <[email protected]> > Cc: "Marshall Clow" <[email protected]>, "Eric Fiselier" <[email protected]>, > "cfe commits" <[email protected]> > Sent: Tuesday, November 11, 2014 2:48:00 PM > Subject: Re: [PATCH] [libc++] reject <chrono> literals that can't be > represented > > > > > On Tue, Nov 11, 2014 at 12:41 PM, Hal Finkel < [email protected] > > wrote: > > > ----- Original Message ----- > > From: "Richard Smith" < [email protected] > > > To: "Marshall Clow" < [email protected] >, "Eric Fiselier" < > > [email protected] >, "cfe commits" < [email protected] > > > Sent: Tuesday, November 11, 2014 2:05:21 PM > > Subject: [PATCH] [libc++] reject <chrono> literals that can't be > > represented > > > > > > > > [time.duration.literals]p3 says: > > > > > > "If any of these suffixes are applied to an integer literal and the > > resulting chrono::duration value cannot be represented in the > > result > > type because of overflow, the program is ill-formed." > > > > > > That's unimplementable in standard C++, but implementable with > > Clang > > using the enable_if attribute. This patch also rejects > > > > > > (void) operator""ns(0x8000000000000000ull); > > > > > > ... and it's not entirely clear whether that's permissible, but > > this > > is the best we can do at the moment (and I think it's a good thing > > to reject the above code). > > > > > > Thoughts? > > 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. > > There already is one: > http://cplusplus.github.io/LWG/lwg-active.html#2383 -- 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.]
Sounds good. I don't really have an opinion on whether we jump the resolution of this issue or not. We might not, however, want to introduce a semi-permanent disparity between the behavior of libc++ compiled with Clang and libc++ compiled with other compilers (by using a Clang-specific extension here). I mention this not because I care, but just in case others might. -Hal -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
