3 ms·

You could call them composite in that sense, but in C, composite types are types that are composed of other C types (structs, unions, arrays, ... functions? Not

You could call them composite in that sense, but in C, composite types are types that are composed of other C types (structs, unions, arrays, ... functions? Not 100% sure of the specifics). Also, the representations of floats and doubles isn't precisely specified, at least IEEE754 is not a strict requirement (not sure about the technical implications from what's actually specified).

jacquesm 3y ago
I'm not the one making the argument, merely explaining why the GGP may have chosen this example.
- jstimpfle 3y ago
  Wasn't implying that! :)
nicoburns 3y ago
I'm not really sure I get why the distinction between composite and non-composite types is important if the only difference is that you can't easily access sub-parts of the non-composite types.
- jstimpfle 3y ago
  I guess we can cook up some arguments about language purity and orthogonality. Introducing literals that create composite types might indeed create some difficulties for existing compilers that want to follow the latest standard.
  - nicoburns 3y ago
    What kind of difficulties? I don't understand why this would make any difference from a compiler's perspective.
    - jstimpfle 3y ago
      It requires the compiler to be able to create types even before parsing, to have composite types without any source code location... you'd have to check with a specific compiler but it's not hard to imagine some potential issues. There's also outward facing changes that introduce complexity... new literal types (+ new syntax) are required because otherwise old could would break (sizeof...) etc. etc. Existing parsers and tooling will have to be adapted, too... Generally it's nothing that should be insurmountable, but why accept any of that if there's nothing to gain except a feature that is requested mainly by detractors of the ecosystem, a feature that goes squarely against the grain of the language...? Any language is proud to be able to implement its features as library components around its core capabilities. Why introduce a new C type as a structure that can easily be defined as an aggregate type in source code?

jacquesm 3y ago

I'm not the one making the argument, merely explaining why the GGP may have chosen this example.

jstimpfle 3y ago
Wasn't implying that! :)

nicoburns 3y ago

I'm not really sure I get why the distinction between composite and non-composite types is important if the only difference is that you can't easily access sub-parts of the non-composite types.

jstimpfle 3y ago
I guess we can cook up some arguments about language purity and orthogonality. Introducing literals that create composite types might indeed create some difficulties for existing compilers that want to follow the latest standard.
- nicoburns 3y ago
  What kind of difficulties? I don't understand why this would make any difference from a compiler's perspective.
  - jstimpfle 3y ago
    It requires the compiler to be able to create types even before parsing, to have composite types without any source code location... you'd have to check with a specific compiler but it's not hard to imagine some potential issues. There's also outward facing changes that introduce complexity... new literal types (+ new syntax) are required because otherwise old could would break (sizeof...) etc. etc. Existing parsers and tooling will have to be adapted, too... Generally it's nothing that should be insurmountable, but why accept any of that if there's nothing to gain except a feature that is requested mainly by detractors of the ecosystem, a feature that goes squarely against the grain of the language...? Any language is proud to be able to implement its features as library components around its core capabilities. Why introduce a new C type as a structure that can easily be defined as an aggregate type in source code?