Am Sun, 04 Jan 2015 18:25:32 +0100 schrieb Martin Nowak <[email protected]>:
> On 01/04/2015 04:50 AM, Mike wrote: > > On Saturday, 3 January 2015 at 14:14:42 UTC, Adam D. Ruppe wrote: > >> What changes did you have in mind? When I played with it, it was > >> mostly using the C-like subset, but I still think it was worth it > >> because bits like operator overloading and slicing are really > >> convenient. > >> > >> What I've wanted before is better ability to remove dependency on > >> stuff like moduleinfo. Though that isn't a big deal on something > >> like x86 where an extra 30 KB is fine, I think it would be really > >> important on something like a arduino. (Which I intend to play > >> with - finally have one here - but haven't gotten around to yet.) > > > > Indeed, by using a C-like subset of D you have a much more powerful > > and convenient language than C. But the compiler is not aware of > > that subset, so it's not a professional experience. That's why it > > plays second fiddle to C. I need that polished experience before I > > can sell D to my employer, my customers, or even myself. > > > > Right now if you step outside of the aforementioned subset, you'll > > only get a linker error. Furthermore, you have limited facilities > > outside of hacks and creative linker scripting to reign in code > > generation. And programmers have to create their own port of the > > runtime to provide that subset, but there is no hope in that port > > every making it upstream, so bare-metal/embedded/kernel programmers > > will always be forced to their own corner of the world, with a > > different dialect of the language. > > The situation is similar to C where you have a specialized nanolib > runtime, have to come up with your own linker script and need to > avoid big dependencies (like printf with float support). > > https://launchpad.net/gcc-arm-embedded > > We already have a designated -betterC compiler switch that should > avoid all dependencies (it's incomplete though). Overall I think this > is fairly trivial to achieve. > > I don't see what part of the runtime would be needed for an embedded > target, except for maybe 2 hooks http://wiki.dlang.org/Runtime_Hooks > or so. If you're using C++, you also need to fill in some missing > runtime functions (__init_array, __cxa_pure_virtual, _sbrk). > > > There have been suggestions to create compiler flag in order > > restrict compilation to a minimal subset of D, but I don't think > > that's the right solution. Programmers will define "minimal" > > differently. For example, I would like to be able to use > > exceptions, but I don't want that to implicitly require the garbage > > collector. > > Exceptions on MC sounds like a bad idea, you can avoid the GC by > throwing static instances of exceptions. > > > Here are some of the changes I had in mind: > > > > 1. Move the runtime hook definitions out of the compiler to .di > > files so programmers wanting to create a subset of the language can > > decorate those definitions, or omit them, in order to get compiler > > errors instead of linker errors when they explicitly or implicitly > > use an unimplemented language feature. > > Maybe for a polished experience, but it's worth the trouble in the > beginning. > > > 2. Add toolchain support (compiler and especially linker) to reign > > in all the implicit code generation and remove dead code. This is > > crucial for microcontroller programming. > > Last time I build an embedded ARM project the resulting D binary was > as small as the C++ one. > > > 3. The GC, and other automatic memory management strategies, should > > be opt-in library features, instead of default language features > > one has to avoid. Other emerging languages have shown that D can > > have much more elegant lifetime management if it broke with the > > past, but it's clear that's not going to happen. > > It's a known issue that certain language constructs require memory > management. That's not a big deal, you can't use C++'s std::map > either. > > > 4. But it's not just a laundry list of individual features that's > > needed. The community and the language leaders need a change in > > perspective. > > A group of people that builds the infrastructure is needed. > > I can't strictly follow your conclusion, that half of the language > needs to be change. > The only thing I needed to do last time, was to disable ModuleInfo > generation in the compiler. > The question is basically if you want a 100% polished experience or if you just want something that works with some effort. One example of many: If you disable ModuleInfo we still happily compile module constructors, they'll never be called though. Sure you can avoid this if you know about it, but we can't promote D as a reasonable replacement for C as long as these issues exist. I agree that such changes are not really big language changes.
