I've started using that phrase in the context of Swift for TensorFlow specifically. The vision there is to provide the full capabilities of your CPU and also accelerators. Swift itself is already pretty great at talking to your CPU and allows you to go down to the metal with unsafe constructs, C interop, etc.
S4TF takes this to the next level with GPUs, TPUs and other accelerators in conjunction with the MLIR compiler infra. The beautiful thing about Swift in this context (particularly compared to Python) is that you get access to the full capabilities of your machine from a single contiguous language and a consistent set of tools.
I appreciate the response. This is very different from what I guessed it meant, not sure why I thought it meant that the language syntax can be modified infinitely to compile to some predefined semantics. This had me confused because I couldn't find any evidence that swift has meta-programming (although there's some really nice features that somewhat reduce that need like trailing closures, so I wondered if there were more like those that I missed).
If I understand correctly it means that the goal is to make Swift the one single language that can compile with multiple backends such as LLVM and MLIR so that the same code can seamlessly be run on CPU/GPU/TPU. The ultimate goal is therefore unifying everything that is currently done in Python + C/C++ + CUDA into one single language removing the boundaries between layers.
Hoping this helps someone else understand, or to get more clarification if I understood wrong.
Proper support for metaprogramming is support important to making this a reality! Please see the August 9, 2019 S4TF open design meeting slides and video for more information on our (very early!) thoughts on this,
wait for a few years for the language to settle down then rewrite its compiler - will it be too late to correct error some design error introduced into the language.
if your use swift daily by reimplementing its compiler, it will help developing the language.
The counter-argument is that maintaining a self-hosting compiler for a language that is itself a moving target can be quite difficult. It can also shape the language design in ways that only benefit compiler development.
Now that Swift is source-stable, it would in theory be more feasible to write a self-hosting compiler, however C++ interoperability is a (highly non-trivial) problem that would have to be solved first, because Swift integrates deeply with LLVM and Clang via their C++ APIs.
Indeed, it's hard to make a good case for rewriting the compiler in Swift; there are so many more meaningful improvements we can deliver by continuing to develop the current codebase rather than throwing it all away.