GSOC - Holiday Edition

[Martin Nowak via Digitalmars-d]

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.