5 ms·

I think Apple’s clang is the one they build the OS with, and they don’t want to run the risk of introducing a compiler bug late into a project. So, they pick w

I think Apple’s clang is the one they build the OS with, and they don’t want to run the risk of introducing a compiler bug late into a project. So, they pick what’s current early in a project and stick with it. They may add a few backports of bug fixes to that, but that’s it. IMO, that’s a good strategy.

_eojb 3y ago
Contrasting opinion, it's a terrible strategy. Limiting the entire ecoystem of devs on your platform to features that have not only shipped but stabilized over 5 years prior on other platforms is nonsensical. Compare to MSFT, which is frankly ahead of the curve when it comes to compiler feature support, and even has the entire STL open sourced.
- Longhanks 3y ago
  > even has the entire STL open sourced. You do realize that everything from llvm/clang, gcc, libc++ to libstdc++ is open source? MSVC is late in that regard (and the compiler itself is as closed as can be).
  - ninepoints 3y ago
    Yes I hack on llvm and clang. Where can I submit a PR to Apple Clang?
- sesuximo 3y ago
  You can absolutely use a different compiler as an apple dev. Just might be a touch tougher to set up a non-standard build
  - watersb 3y ago
    Sorry, this might be a dumb question, but I'm not sure what you mean by "as an Apple dev". I assume you mean "as a developer [anybody] developing software on an Apple platform". I would be surprised if Apple employees were free to choose their compiler.
lenkite 3y ago
Compiler version used to compile the OS mandating same compiler version to compile all apps for the OS is a very head-scratching strategy.
- ninkendo 3y ago
  It’s commonly known as dogfooding, and it’s a very common (and I’d argue, the correct) strategy. It’s more head scratching IMO for there to be two standards on compiler stability.
  - menaerus 3y ago
    There are no two standards on compiler stability - there is one and it is called ABI. What Apple chose is rather an outstanding case and not really common when you consider all the operating systems and their flavors.
    - ninkendo 3y ago
      If we were to presuppose that Apple already has a new compiler version that works with new C++ features, but doesn’t think it’s ready yet, than IMO it stands to reason that they’re also not confident that the ABI emitted by said compiler will be something they’re ready to support forever. It’s a bad idea to say “go ahead and compile with an unsupported compiler, and we’ll just support the ABI it emits in perpetuity even though we have already admitted it’s not stabilized yet.”
      - menaerus 3y ago
        How else do you imagine different compiler vendors with loath of varying compiler versions work on other Unices?
        ninkendo 3y ago
        They define a de facto ABI for their compiler, and once they’re confident enough that the code emitted by their compiler actually works and adheres to it, they take it out of beta and say it’s ready to use. No sooner than that. Not sure what you’re asking here. Remember that supporting C++ features isn’t just about emitting code, it’s about the implementation of libstdc++/libc++ that you have to make sure you don’t paint yourself into a corner with. It’s easy to accidentally write code that needs to be linked to one way, then later on in the development cycle, subtly change it in a way that changes a symbol, or a type layout, etc. This is all fiddly work that they have to spend time getting right. You mention other compiler vendors: I remember very distinctly times when GCC would change the ABI to libstdc++. I was running Debian sid at the time and there was basically a month where the OS was not usable at all, as packages had to be recompiled against the new libstdc++. These kinds of issues happen where, if you let people use a complier (and its corresponding stdlib implementation) before it’s ready, you may find that you have to break ABI in order to fix issues with your new language support, and you leave people stranded who may have already compiled their code against the old stdlib.

_eojb 3y ago

Contrasting opinion, it's a terrible strategy. Limiting the entire ecoystem of devs on your platform to features that have not only shipped but stabilized over 5 years prior on other platforms is nonsensical. Compare to MSFT, which is frankly ahead of the curve when it comes to compiler feature support, and even has the entire STL open sourced.

Longhanks 3y ago
> even has the entire STL open sourced. You do realize that everything from llvm/clang, gcc, libc++ to libstdc++ is open source? MSVC is late in that regard (and the compiler itself is as closed as can be).
- ninepoints 3y ago
  Yes I hack on llvm and clang. Where can I submit a PR to Apple Clang?
sesuximo 3y ago
You can absolutely use a different compiler as an apple dev. Just might be a touch tougher to set up a non-standard build
- watersb 3y ago
  Sorry, this might be a dumb question, but I'm not sure what you mean by "as an Apple dev". I assume you mean "as a developer [anybody] developing software on an Apple platform". I would be surprised if Apple employees were free to choose their compiler.

lenkite 3y ago

Compiler version used to compile the OS mandating same compiler version to compile all apps for the OS is a very head-scratching strategy.

ninkendo 3y ago
It’s commonly known as dogfooding, and it’s a very common (and I’d argue, the correct) strategy. It’s more head scratching IMO for there to be two standards on compiler stability.
- menaerus 3y ago
  There are no two standards on compiler stability - there is one and it is called ABI. What Apple chose is rather an outstanding case and not really common when you consider all the operating systems and their flavors.
  - ninkendo 3y ago
    If we were to presuppose that Apple already has a new compiler version that works with new C++ features, but doesn’t think it’s ready yet, than IMO it stands to reason that they’re also not confident that the ABI emitted by said compiler will be something they’re ready to support forever. It’s a bad idea to say “go ahead and compile with an unsupported compiler, and we’ll just support the ABI it emits in perpetuity even though we have already admitted it’s not stabilized yet.”
    - menaerus 3y ago
      How else do you imagine different compiler vendors with loath of varying compiler versions work on other Unices?
      - ninkendo 3y ago
        They define a de facto ABI for their compiler, and once they’re confident enough that the code emitted by their compiler actually works and adheres to it, they take it out of beta and say it’s ready to use. No sooner than that. Not sure what you’re asking here. Remember that supporting C++ features isn’t just about emitting code, it’s about the implementation of libstdc++/libc++ that you have to make sure you don’t paint yourself into a corner with. It’s easy to accidentally write code that needs to be linked to one way, then later on in the development cycle, subtly change it in a way that changes a symbol, or a type layout, etc. This is all fiddly work that they have to spend time getting right. You mention other compiler vendors: I remember very distinctly times when GCC would change the ABI to libstdc++. I was running Debian sid at the time and there was basically a month where the OS was not usable at all, as packages had to be recompiled against the new libstdc++. These kinds of issues happen where, if you let people use a complier (and its corresponding stdlib implementation) before it’s ready, you may find that you have to break ABI in order to fix issues with your new language support, and you leave people stranded who may have already compiled their code against the old stdlib.