[Cfp-interest 2982] Re: [SC22WG14.24554] background regarding complex and imaginary types

[Alex Celeste]

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?

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.

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.
So I don't entirely buy the argument that this is not worth providing just
because of duplication.

(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)

Thanks,

Alex


On Fri, 19 Jan 2024 at 10:51, Jₑₙₛ Gustedt <jens.gustedt at inria.fr> wrote:

> Jim,
> thanks for that paper, this is indeed helpful!
>
> So I take it that there has only been one historic implementation of
> imaginary types, and that implementation is not maintained any more?
>
> For the take on the i suffix, I don't agree. Integrating this into the
> language as a proper literals is much more that just having `I`. In
> fact, with such literals an application that uses complex numbers
> would not even necessarily have to include `<complex.h>` anymore. With
> C23, presence of any header file can be tested with `__has_include`
> and so we can separate support for complex numbers in section 6 from
> support of complex numerical algorithms in section 7. Basically the
> macros in the header that are merely type support and not "real"
> library would become obsolete.
>
> So this is definitively not just cosmetics.
>
> Also I don't get the point on using `y*I` and not being able to use
> the suffix, there. I don't see `y*1.IF` as much more complex to write
> than that.
>
> Currently I don't see that any of the existing implementations that
> have support for complex could even switch to use imaginary types,
> because since we have type inspection (C11 `_Generic` for example) the
> value of `I` is pretty much part of the corresponding ABI. (And C23
> `auto` and `typeof` will enforce this.)
>
> The example of multiplication with an pure imaginary value and some
> complex infinity shows that this might have been a good idea, but also
> that nobody in the application world seems ever to have cared enough
> about such boundary cases to motivate an implementation of this
> feature.
>
> Thanks
> Jₑₙₛ
>
> --
> :: ICube :::::::::::::::::::::::::::::: deputy director ::
> :: Université de Strasbourg :::::::::::::::::::::: ICPS ::
> :: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus ::
> :: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
> :: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20240119/d5b59091/attachment.htm>