On Tuesday, 20 June 2017 at 12:32:46 UTC, Dan Walmsley wrote:
If we push to have this fixed after that we are pretty close to having something usable are we not?
Depends on your definition of "usable". Fixing the bloat issue would remove a current road block, and at least allow progress to continue.
IMO, to make D a pleasant experience on the ARM Cortex-M platform, we'll need to implement the entire druntime including threading, GC, exceptions, dynamic arrays, etc... even if those features are not used. This is because D just hasn't been designed and implemented in a modular fashion to allow one to pay-as-they-go, and as you experienced in one of your other posts today, you just get too many undefined references and other odd errors that have nothing to do with your code. The only way to make those errors go away is to ensure everything in druntime is there.
If the bloat problem were solved, we could at least continue working towards that end. But it's not immediately apparent to me how much overhead a complete runtime implementation will add to as simple microcontroller application, and how well the compiler and linker can optimize and remove that overhead. We may encounter other roadblocks like I did with the TypeInfo bloat, and have to fight a major battle to get something done about it.
But I don't want to have to implement the entire druntime in order to start making progress. It shouldn't have to be that way.
Mike
