<div dir="ltr"><div>It's kinda the least important aspect of this, but w.r.t the suffixes: in practice, from a tool perspective, aren't these likely easier/cleaner to provide than the corresponding macros anyway?<br><br></div><div>The macros require that the tool have a) an awareness of these types in the type system, so they can't truly be a pure-library feature; and b) have some _underlying_ way to create objects of these types, that the macros are the interface to. As far as I'm aware that means that a tool vendor's options are to implement the suffix extension anyway, to use it as the most straightforward implementation of the macros; to add a `__builtin` just for this; or to do some ugly pointer-casting by populating an array[2] of reals and then reinterpreting it.</div><div><br></div><div>And if they're going to go most of the way towards providing the extension anyway, they may as well do it in a way that exposes the more elegant version of the syntax to the user for the cases when the elegant syntax can be used.</div><div>So I don't entirely buy the argument that this is not worth providing just because of duplication.<br></div><div><br></div><div>(also GCC has kinda firmly established praxis here, users expect the `i` suffix to exist now, and casual users tend to hate `I` for its disruptive namespacing effect)</div><div><br></div><div>Thanks,</div><div><br></div><div>Alex</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 19 Jan 2024 at 10:51, Jₑₙₛ Gustedt <<a href="mailto:jens.gustedt@inria.fr">jens.gustedt@inria.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Jim,<br>
thanks for that paper, this is indeed helpful!<br>
<br>
So I take it that there has only been one historic implementation of<br>
imaginary types, and that implementation is not maintained any more?<br>
<br>
For the take on the i suffix, I don't agree. Integrating this into the<br>
language as a proper literals is much more that just having `I`. In<br>
fact, with such literals an application that uses complex numbers<br>
would not even necessarily have to include `<complex.h>` anymore. With<br>
C23, presence of any header file can be tested with `__has_include`<br>
and so we can separate support for complex numbers in section 6 from<br>
support of complex numerical algorithms in section 7. Basically the<br>
macros in the header that are merely type support and not "real"<br>
library would become obsolete.<br>
<br>
So this is definitively not just cosmetics.<br>
<br>
Also I don't get the point on using `y*I` and not being able to use<br>
the suffix, there. I don't see `y*1.IF` as much more complex to write<br>
than that.<br>
<br>
Currently I don't see that any of the existing implementations that<br>
have support for complex could even switch to use imaginary types,<br>
because since we have type inspection (C11 `_Generic` for example) the<br>
value of `I` is pretty much part of the corresponding ABI. (And C23<br>
`auto` and `typeof` will enforce this.)<br>
<br>
The example of multiplication with an pure imaginary value and some<br>
complex infinity shows that this might have been a good idea, but also<br>
that nobody in the application world seems ever to have cared enough<br>
about such boundary cases to motivate an implementation of this<br>
feature.<br>
<br>
Thanks<br>
Jₑₙₛ<br>
<br>
-- <br>
:: ICube :::::::::::::::::::::::::::::: deputy director ::<br>
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::<br>
:: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus ::<br>
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::<br>
:: <a href="https://icube-icps.unistra.fr/index.php/Jens_Gustedt" rel="noreferrer" target="_blank">https://icube-icps.unistra.fr/index.php/Jens_Gustedt</a> ::<br>
</blockquote></div>