<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 26 May 2017 at 10:34, Tim Northover via cfe-commits <span dir="ltr"><<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 24 May 2017 at 17:54, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
> Yikes :-( Maybe libc++ *should* have that extension then. It sounds like<br>
> we'll silently get the wrong value for any attempt at std::complex /<br>
> _Complex interop right now:<br>
<br>
</span>That sounds like a pretty good idea whatever we decide to do about the literals.<br>
<br>
But we do need to sort out what we're going to do here. I quite like<br>
the approach you suggested, and think it's an improvement worth<br>
putting in for gnu++ modes regardless.<br>
<br>
So the remaining question is what we should do for the<br>
standards-compliant C++ modes. We seem to have 3 plausible options:<br>
<br>
1. Bar it everywhere. It's an extension.<br>
2. Bar it for C++14 onwards, where the standard provides literals.<br>
3. Allow it everywhere.<br>
<br>
Although 2 would be the most conservative option (it maintains all<br>
existing behaviour), it's my least favourite for the added complexity<br>
and quirkiness.<br>
<br>
My original inclination is to go with Marshall and pick 1, but it's a<br>
very weak preference and I know I tend to be a bit user-hostile in<br>
these situations.<br>
<br>
So, how do we resolve this. Does anyone else have opinions?</blockquote><div><br></div><div>Generally I'd also side towards 1, but in this instance that would mean we're removing a conforming extension that prior versions of clang supported in C++98 and C++11 modes, with no way to get the extension back other than turning on the full set of (non-conforming) GNU extensions.</div><div><br></div><div>I quite like the approach we take to MS extensions: we have two separate flags for the conforming and non-conforming extensions. For GNU extensions, we generally do the same, where the conforming extensions are enabled by default (with no way to turn them off other than -pedantic-errors or -Werror=gnu!) and the non-conforming extension controlled by -std=gnu* vs -std=c* ("GNU mode"). (In the longer term, I'd like to replicate the MS pattern for the GNU extensions, with -fgnu-extensions controlling the conforming extensions and -fgnu-compatibility controlling the non-conforming extensions.)</div><div><br></div><div>If we generally think that distinction is a good thing, then (because this is a conforming extension) consistency weakly suggests that it should not be controlled by GNU mode. But I don't find that argument decisive; the important thing is that we don't enable non-conforming extensions by default in non-GNU (and non-MS-compat) modes, not that GNU mode consists of /only/ non-conforming extensions.</div><div><br></div><div>Given that we probably want to retain a way to enable this outside GNU mode, if we go for 1, then we would want a separate flag to enable it, and then the difference between 1 and 3 is whether it's a -f flag or a -W flag. The latter is our normal choice for such conforming extensions.</div><div><br></div><div><br></div><div>Looking at the</div><div><br></div><div>  std::complex<float> x = 1.0if;</div><div><br></div><div>case again, I think there's another problem here: we support an implicit conversion from _Complex float to float in C++ (without even a warning). This conversion is valid in C, but at least GCC disallows it in its C++ mode. We should probably at least warn on that.</div></div></div></div>