www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Current state of "D as a better C" (Windows)?

reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
Hi,

What's the current situation of using D without Phobos/Druntime?

Sometimes, it's quite useful to be able to use D to create tiny 
EXEs/DLLs. For example, create simple DLL plugins that will be 
loaded into non-D programs, or even not have a 50-line program 
take half a meg. Additionally, some tasks require injecting a DLL 
systemwide (into every running process), so it is critical to 
minimize the impact by being as unintrusive as possible and 
having a minimal overhead.

I've started a "framework" for this purpose a while ago[1], but I 
heard of people starting similar projects since then and I think 
they've gotten further than me. Would there be any interest in 
collaborating and turning this into a community project?

I think some goals would be:
- A "runtime" (object.d) which provides either stubs for the 
current compiler hooks, or implementations with minimal 
dependencies
- A "standard library" which does not require runtime support, 
but can also be used when using Druntime (as a GC-free 
alternative to Phobos)
- Using MSVCRT on 32-bit as well
- Options to enable/disable various runtime features? For 
example, a project may want to use exceptions (which requires 
ClassInfo) but not the GC.
- Support for the Unilink linker? I think it is better at 
generating smaller binaries that OPTLINK.

There is also some ongoing work on the -betterC switch[2], which 
I'm quite excited about, but it seems to be currently blocked on 
waiting for the next DMD release as the changes[3] might break a 
lot of code.

  [1]: https://github.com/CyberShadow/SlimD
  [2]: https://d.puremagic.com/issues/show_bug.cgi?id=11881
  [3]: https://github.com/D-Programming-Language/dmd/pull/2561
Jan 21 2014
next sibling parent reply "Mike" <none none.com> writes:
On Wednesday, 22 January 2014 at 02:18:43 UTC, Vladimir Panteleev 
wrote:

 Hi,

 What's the current situation of using D without Phobos/Druntime?


I created a minimal, no runtime, "hello world" program [1], and I 
think Iain Buclaw answered your question when he commented on my 
example as follows:

"that's not D! That's some D, a bit of some extended inline 
assembly, and a custom linker script."

To paraphrase, if you really want the best of what D has to 
offer, you'll need to implement a good part of the runtime.  But 
I argue, not all of it.

I'm working on a bare-metal ARM Cortex-M _very minimal_ port of 
the D runtime with an emphasis on "minimal". I just created my 
repository and started documenting my progress [2].  It's in the 
very early stages, and I am quite new to D, so I have quite a 
ways to go, but my goals align with your stated intent.

I'm able to do structs with just a few line of stubbed TypeInfo 
stuff in my object.d.  I've reduced it to 21 lines [3].

I've also implemented a simple malloc/free and am able to do 
classes, but I haven't tested any D feature thoroughly yet.


 Sometimes, it's quite useful to be able to use D to create tiny 
 EXEs/DLLs. For example, create simple DLL plugins that will be 
 loaded into non-D programs, or even not have a 50-line program 
 take half a meg. Additionally, some tasks require injecting a 
 DLL systemwide (into every running process), so it is critical 
 to minimize the impact by being as unintrusive as possible and 
 having a minimal overhead.

 I've started a "framework" for this purpose a while ago[1], but 
 I heard of people starting similar projects since then and I 
 think they've gotten further than me. Would there be any 
 interest in collaborating and turning this into a community 
 project?


Didn't know about SlimD (catchy name by the way).  I'll 
definitely be taking a look as this aligns with my goals.

As the Cortex-M microcontrollers have very little FLASH memory, 
it is also important for me to reduce the executable size, and 
I'm focusing on that in my project.  I've been able to get my 
"Hello, World!" program down to 68 bytes, with 15 of those bytes 
being the "Hello, World!\r\n" string constant.


 I think some goals would be:
 - A "runtime" (object.d) which provides either stubs for the 
 current compiler hooks, or implementations with minimal 
 dependencies


I would really like to see a more modular D runtime in which 
features of the D language can be selectively chosen.  This is 
one of my goals.  I'd also like to have the D runtime 
"reorganzied" to make hardware/OS/C-library abstraction more 
obvious.  I submitted an enhancement to facilitate this [4]:

I thin, a modular, well-organized, well-abstracted, D runtime 
will facilitate both your stated intention and my goals to bring 
D to the microcontroller world, and will also facilitate bringing 
D to a variety of other platforms as well.  But, I really think 
the D runtime needs some refactoring to achieve this.

In my project, I'm also trying to do everything in D ("Look, 
Walter!,  No C!").  I'd like to see all the references to C's 
baggage left separate from the rest of the D runtime, included 
"size_t".  Let's not track C's doo-doo into D's house, if it can 
be avoided.


 - A "standard library" which does not require runtime support, 
 but can also be used when using Druntime (as a GC-free 
 alternative to Phobos)


Phobos will not be useful to me unless I can find some way to 
make it lighter and GC-Free.  I'll probably just end up taking 
pieces of it.  I would _really_ like to have the whole concept of 
a GC decoupled from D.  There are many suitable memory models to 
use with D, and the memory model seems like it should be a 
platform feature, not a language feature.  But, I don't know how 
one could accomplish that without some changes to the language 
itself, and it seems the core language folks have their hands 
full.


 - Options to enable/disable various runtime features? For 
 example, a project may want to use exceptions (which requires 
 ClassInfo) but not the GC.


Yes, this definitely aligns with my goals, see my comment above 
about a modular D runtime.  But I wouldn't necessarily be in 
favor of adding switches to the compiler, as I don't like to be 
at the mercy of the compiler implementers.  I'd prefer some way 
where I can pass a user-defined variable to my compiler flags in 
concert with the version() feature.  And if something is needed, 
but not implemented, the compiler/linker will throw an error 
saying so.


 - Support for the Unilink linker? I think it is better at 
 generating smaller binaries that OPTLINK.


Does D have to support Unilink, or does Unilink have to support D?


 There is also some ongoing work on the -betterC switch[2], 
 which I'm quite excited about, but it seems to be currently 
 blocked on waiting for the next DMD release as the changes[3] 
 might break a lot of code.

  [1]: https://github.com/CyberShadow/SlimD
  [2]: https://d.puremagic.com/issues/show_bug.cgi?id=11881
  [3]: https://github.com/D-Programming-Language/dmd/pull/2561


There was an interesting discussion, recently, that might 
relevant to this.  I encourage you to check it out and maybe post 
your thoughts [5]. It's more about the required TypeInfo stuff, 
but nevertheless related to the -betterC idea.

LCD has some pragmas that seem to align with the general idea of 
what you're looking for [6], and GDC has the -fno-emit-moduleinfo 
which is essential for what I'm doing.

I'd love to contribute to something like this in anyway I can, 
but I'd probably be asking more questions than providing help.  
At the moment, my contribution is in the form of my repository 
[2].  I hope it will have some influence in the long run, and 
maybe when I come up to speed on the language I'll be able to 
contribute more.

Mike

[1] 
http://wiki.dlang.org/Minimal_semihosted_ARM_Cortex-M_%22Hello_World%22
[2] https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study
[3] 
https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/blob/structs/source/object.d
[4] https://d.puremagic.com/issues/show_bug.cgi?id=11666
[5] 
http://forum.dlang.org/post/jynxfglpulguvqbivrms forum.dlang.org
[6] http://wiki.dlang.org/LDC-specific_language_changes
Jan 21 2014
next sibling parent reply "Dominikus Dittes Scherkl" writes:
On Wednesday, 22 January 2014 at 04:13:41 UTC, Mike wrote:

 Didn't know about SlimD (catchy name by the way).


Would be even better if D2 had been named "E" :-D
Jan 22 2014
parent "Atila Neves" <atila.neves gmail.com> writes:
On Wednesday, 22 January 2014 at 09:37:00 UTC, Dominikus Dittes 
Scherkl wrote:

 On Wednesday, 22 January 2014 at 04:13:41 UTC, Mike wrote:

 Didn't know about SlimD (catchy name by the way).


 Would be even better if D2 had been named "E" :-D


I still think that the original name "Mars" was far better, never 
mind the fact that it would've been far easier to Google. Ah well.

Atila
Jan 22 2014
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
Hi Mike, thanks for the extensive reply.

On Wednesday, 22 January 2014 at 04:13:41 UTC, Mike wrote:

 To paraphrase, if you really want the best of what D has to 
 offer, you'll need to implement a good part of the runtime.  
 But I argue, not all of it.


Well, even C with D's metaprogramming would be a big win. But 
picking-and-choosing runtime-supported features would be even 
better.


 I'm working on a bare-metal ARM Cortex-M _very minimal_ port of 
 the D runtime with an emphasis on "minimal". I just created my 
 repository and started documenting my progress [2].  It's in 
 the very early stages, and I am quite new to D, so I have quite 
 a ways to go, but my goals align with your stated intent.

 I'm able to do structs with just a few line of stubbed TypeInfo 
 stuff in my object.d.  I've reduced it to 21 lines [3].

 I've also implemented a simple malloc/free and am able to do 
 classes, but I haven't tested any D feature thoroughly yet.

 As the Cortex-M microcontrollers have very little FLASH memory, 
 it is also important for me to reduce the executable size, and 
 I'm focusing on that in my project.  I've been able to get my 
 "Hello, World!" program down to 68 bytes, with 15 of those 
 bytes being the "Hello, World!\r\n" string constant.


This is quite cool.

I noticed you're using GNU make. On Windows, D uses Digital Mars 
make, which is quite minimalistic. I've considered writing a 
custom build tool for SlimD, but now that I think about it, I 
think GNU make will suffice.


 I would really like to see a more modular D runtime in which 
 features of the D language can be selectively chosen.  This is 
 one of my goals.

 I thin, a modular, well-organized, well-abstracted, D runtime 
 will facilitate both your stated intention and my goals to 
 bring D to the microcontroller world, and will also facilitate 
 bringing D to a variety of other platforms as well.  But, I 
 really think the D runtime needs some refactoring to achieve 
 this.


So, you think it would be better to make the standard D runtime 
more customizable in this regard, instead of putting together a 
new one?

I believe the biggest factor for why someone would want to use a 
lighter runtime is the garbage collector. I think a lot of the 
code in Druntime still assumes that a GC is present... and then 
I'm not sure the D maintainers would want to maintain support for 
such rarely-needed features such as a custom entry point. (Case 
in point: pragma(entrypoint, symbol) has been broken since DMD 
2.061.)


 In my project, I'm also trying to do everything in D ("Look, 
 Walter!,  No C!").  I'd like to see all the references to C's 
 baggage left separate from the rest of the D runtime, included 
 "size_t".


What's wrong with size_t?

On Windows, it is quite necessary if you want to target both 
32-bit and 64-bit (and if you want to do system-wide DLL 
injection, that's an absolute requirement).


 Phobos will not be useful to me unless I can find some way to 
 make it lighter and GC-Free.  I'll probably just end up taking 
 pieces of it.  I would _really_ like to have the whole concept 
 of a GC decoupled from D.  There are many suitable memory 
 models to use with D, and the memory model seems like it should 
 be a platform feature, not a language feature.  But, I don't 
 know how one could accomplish that without some changes to the 
 language itself, and it seems the core language folks have 
 their hands full.


There have been discussions of a compiler switch or  attribute to 
make implicit allocations (such as array literals, or heap 
closures) generate compiler errors.


 Yes, this definitely aligns with my goals, see my comment above 
 about a modular D runtime.  But I wouldn't necessarily be in 
 favor of adding switches to the compiler, as I don't like to be 
 at the mercy of the compiler implementers.


I agree that hacking or forking the compiler should be avoided 
and left as a last resort. By "switches" I meant per-project 
(e.g. makefile) options.


 Does D have to support Unilink, or does Unilink have to support 
 D?


Well, neither. The "framework" would need to support linking your 
project with Unilink if you indicate that preference in your 
project's build configuration.


 There was an interesting discussion, recently, that might 
 relevant to this.  I encourage you to check it out and maybe 
 post your thoughts [5]. It's more about the required TypeInfo 
 stuff, but nevertheless related to the -betterC idea.


Well, as long as the linker throws away all compiler-emitted 
TypeInfo objects if your code doesn't use them, there doesn't 
seem to be any practical problem with them, is there?


 LCD has some pragmas that seem to align with the general idea 
 of what you're looking for [6], and GDC has the 
 -fno-emit-moduleinfo which is essential for what I'm doing.


ModuleInfo IS a problem, though. It is like a parasite of 
interdependence: it points towards all class information (for 
Object.factory), which itself pulls in all virtual methods of all 
classes in your program (through the Vtable). That means that 
anything that any virtual method in your program uses, regardless 
if you use that class or not, WILL end up in the executable. Ugh!


 I'd love to contribute to something like this in anyway I can, 
 but I'd probably be asking more questions than providing help.  
 At the moment, my contribution is in the form of my repository 
 [2].  I hope it will have some influence in the long run, and 
 maybe when I come up to speed on the language I'll be able to 
 contribute more.


Maybe we could join efforts, even though our goals target 
different platforms :)

What do you say to this repository structure (inspired by the 
Windows DDK):

Users start a new SlimD (or whatever name) project by adding a 
Makefile to their project directory. The makefile configures the 
project's requirements (target platform, used D features, linker 
of choice) and source files (*.d by default), and includes the 
main SlimD makefile, which does all the work based on the given 
configuration.
Jan 23 2014
next sibling parent reply "Mike" <none none.com> writes:
On Thursday, 23 January 2014 at 22:39:38 UTC, Vladimir Panteleev 
wrote:

 Well, even C with D's metaprogramming would be a big win. But 
 picking-and-choosing runtime-supported features would be even 
 better.


Quite right!  I have actually delayed implementing classes a 
little bit because I found I could do so much with just structs, 
mixins, and templates.  In fact, if there weren't so many types 
in the runtime implemented as classes, I could delay it even 
further.


 I noticed you're using GNU make. On Windows, D uses Digital 
 Mars make, which is quite minimalistic. I've considered writing 
 a custom build tool for SlimD, but now that I think about it, I 
 think GNU make will suffice.


Using GNU make was really an arbitrary decision for me.  I really 
don't like GNU make and hate my own makefiles even more.  
Personally, I would prefer to write scripts in D, so I could 
automate whatever I wanted including builds.

My project, however, is just an exercise.  I expect to go through 
this exercise a couple times and fine tune what I want.  Then 
I'll make a real repository with just the good stuff :-)


 So, you think it would be better to make the standard D runtime 
 more customizable in this regard, instead of putting together a 
 new one?


At the moment, I think throwing it all away and starting from 
scratch is the best approach, especially with the 
"minimal/modular" mindset, but I would like to get to a point 
where the two could be integrated (either I join D, or D joins 
me).  I would prefer not to fragment D into "D", "D for 
embedded", "D for smartphones", "D for tablets", etc..  I think 
if the D runtime were modular and designed with platform ubiquity 
in mind, it would simply require a customized makefile like 
you've already alluded to, or something other approach (see my 
comments below)


 What's wrong with size_t?


There's nothing wrong with the concept of size_t.  The problem is 
the "_t" suffix.  That is C's baggage, and is inconsistent with 
other types in D.  D doesn't use string_t, uint_t, etc..., so I 
don't see why this convention is being employed in D.



 There was an interesting discussion, recently, that might 
 relevant to this.  I encourage you to check it out and maybe 
 post your thoughts [5]. It's more about the required TypeInfo 
 stuff, but nevertheless related to the -betterC idea.


 Well, as long as the linker throws away all compiler-emitted 
 TypeInfo objects if your code doesn't use them, there doesn't 
 seem to be any practical problem with them, is there?


Yeah, that's the conclusion I eventually came to.  It was just a 
major inconvenience for me to have to spend hours studying and 
implementing all of this TypeInfo stuff, and all the stuff the 
TypeInfo uses, only to have it thrown away at link time.  It was 
a huge waste of effort, but all that TypeInfo stuff may be needed 
in the end anyway, so I'm holding back too much harsh judgement 
at the moment.


 ModuleInfo IS a problem, though. It is like a parasite of 
 interdependence: it points towards all class information (for 
 Object.factory), which itself pulls in all virtual methods of 
 all classes in your program (through the Vtable). That means 
 that anything that any virtual method in your program uses, 
 regardless if you use that class or not, WILL end up in the 
 executable. Ugh!


That sounds very undesirable.  I still don't even understand what 
purpose modules and ModuleInfo really serve.  Right now, I'm just 
using modules for namespace scope and encapsulation.  If you know 
some documentation that helps demystify ModuleInfo and what its 
purpose is (besides the source code) please point me to it.


 Maybe we could join efforts, even though our goals target 
 different platforms :)

 What do you say to this repository structure (inspired by the 
 Windows DDK):

 Users start a new SlimD (or whatever name) project by adding a 
 Makefile to their project directory. The makefile configures 
 the project's requirements (target platform, used D features, 
 linker of choice) and source files (*.d by default), and 
 includes the main SlimD makefile, which does all the work based 
 on the given configuration.


This is very much like what I had in mind, and I like it.  
However, I'm considering other methods, too.

1) Features/platforms can simply be provide at link time by 
adding a certain *.a or *.o files to the linker command.  And if 
a needed feature is missing, linker errors will result.

For example, exception handling could be provide with seh.o, 
eh.o, sjlj.o, or no_eh.o depending on which model the user wanted 
to use. (This example may not make any sense, as I know nothing 
about how to implement exception handling.  I just couldn't think 
of better illustration of my thoughts).

2) Templates can be used to provide modularity/specialization in 
one's source code at compile time.  There's a C++ graphics 
library [1] that uses this approach to create platform 
independent rendering pipelines.  For example:

//pseudo code
typedef color_t
typedef pixel_t
typedef path_t
typedef surface<pixel_t> surface_t
typedef rasterizer<path_t> rasterizer_t
typedef renderer<rasterizer_t, surface_t> renderer_t.

//Then draw like this
renderer_t r;
r.DrawLine()
r.DrawCircle()
...

So, surface_t could be defined as...

typedef surface<DirectX11> surface_t
typedef surface<OpenGL> surface_t
typedef surface<X11> surface_t

... to provide some platform specialization at compile time, and 
the user of the code doesn't know the difference.

This is a pretty cool way to build a graphics library, and 
something along these lines could be used to provide some 
specialization to the D runtime too.  User's would simply have to 
include a certain *.di file containing the required templated 
aliases/typedefs for a given platform.  If user's want to port to 
a different platform, or choose a different feature subset, they 
just create a different set of templated aliases/typedefs.

I'm brainstorming as I write this, so sorry for being so verbose. 
  As you can see I don't have any opinion yet.  Perhaps you could 
provide your opinion.

Nevertheless, your proposed solution does basically what I'm 
looking for, and would be happy to help in any way I can.

Mike

[1] - http://www.antigrain.com/
Jan 23 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-01-24 06:17, Mike wrote:


 That sounds very undesirable.  I still don't even understand what
 purpose modules and ModuleInfo really serve.  Right now, I'm just using
 modules for namespace scope and encapsulation.  If you know some
 documentation that helps demystify ModuleInfo and what its purpose is
 (besides the source code) please point me to it.


ModuleInfo contains, for example, module constructors:

module foo;

static this () { // run once before every thread is started }
shared static this () { // run once before main is called }

It also provides a way to iterate all modules, at runtime. From each 
module it's possible to iterate all local classes and all imported 
modules. Object.create which will return a new object of a class given 
by its fully qualified name, as a string. Object.create is implemented 
using ModuleInfo.

-- 
/Jacob Carlborg
Jan 24 2014
prev sibling parent "Mike" <none none.com> writes:
On Thursday, 23 January 2014 at 22:39:38 UTC, Vladimir Panteleev 
wrote:

 I believe the biggest factor for why someone would want to use 
 a lighter runtime is the garbage collector. I think a lot of 
 the code in Druntime still assumes that a GC is present... and 
 then I'm not sure the D maintainers would want to maintain 
 support for such rarely-needed features such as a custom entry 
 point. (Case in point: pragma(entrypoint, symbol) has been 
 broken since DMD 2.061.)


The GC seems to be the biggest issue here, so I wanted to comment 
separately.

Each target/platform/application will have different requirements 
and those requirements will dictate the type of memory management 
implementation to use.

Ideally, I don't see why D has to be a garbage collected 
language.  Can't it be agnostic to the memory management 
implementation?

D seems to offer several options to the programmer, Scoped, 
RefCounted, new/destroy, and can even create their own garbage 
collection with the gcstub (or so I've heard).  This is great!, 
but it's not idea as it forces the programmer to change their 
idioms.  It appears that D is very tightly coupled to the memory 
management implementation, but does it need to be?

Couldn't the runtime provide some hooks that can be used by the 
runtime implementation to know when a class is instantiated, when 
it goes out of scope, when it's assigned to another reference, 
etc... and use this to provide a variety of different memory 
management implementations without the programmer having to 
change their idioms?  I'm hypothesizing that if these runtime 
hooks existed, one could create a transparent reference-counted 
implementation that would be mostly transparent to the 
programmer, for example. I still think the programmer will have 
to write code with their memory management implementation in 
mind, but they could at least stick to the same idioms.

I'm not very optimistic, but I'm hoping something like this can 
be achieved, and that's what I'm shooting for.  Absent this 
possibility, I'm not sure what to do.

I believe there is probably a GC implementation that would be 
suitable for a my target platform (ARM Cortex-M 
microcontrollers).  I can think of at least one:  Some firmware 
for microcontrollers simply need to allocate all of their objects 
at the start of the program, but have no need to free memory: 
free is the power switch.  For applications like this only 
gc.allocate() needs to be implemented, and the GC's background 
thread and gc.free() do not.  I think this would allow the 
programmer to stick with traditional D idioms, but they have to 
keep in mind gc.free() will never be and should never be called.  
Some compile-time guarantee here would be nice.

I could go on and on about some of my ideas, but I think I've 
said enough for now.  I've got a lot to learn first, anyway.

Mike
Jan 24 2014
prev sibling next sibling parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 22 January 2014 at 02:18:43 UTC, Vladimir Panteleev 
wrote:

 What's the current situation of using D without Phobos/Druntime?


With LDC I had to figure out how to make the compiler happy, but 
eventually got the job done.


 Sometimes, it's quite useful to be able to use D to create tiny 
 EXEs/DLLs. For example, create simple DLL plugins that will be 
 loaded into non-D programs, or even not have a 50-line program 
 take half a meg. Additionally, some tasks require injecting a 
 DLL systemwide (into every running process), so it is critical 
 to minimize the impact by being as unintrusive as possible and 
 having a minimal overhead.

 I've started a "framework" for this purpose a while ago[1], but 
 I heard of people starting similar projects since then and I 
 think they've gotten further than me. Would there be any 
 interest in collaborating and turning this into a community 
 project?


A framework doesn't seem like a good idea. You can have either 
big framework or small executable, not both.

My code works with stock object.d just fine. In order to make 
injectable dll you only have to disable GC (and probably tls), 
and write otherwise normal D code.
Jan 22 2014
parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 22 January 2014 at 11:13:53 UTC, Kagamin wrote:

 On Wednesday, 22 January 2014 at 02:18:43 UTC, Vladimir 
 Panteleev wrote:

 I've started a "framework" for this purpose a while ago[1], 
 [...]


 A framework doesn't seem like a good idea. You can have either 
 big framework or small executable, not both.


I don't think you and I mean the same things ;) That's why I put 
"framework" in quotes. It was the most suitable word that came to 
mind - I basically meant "standard library and build system for 
your program". My goal is definitely not to replace one 
kitchen-sink library with another.


 My code works with stock object.d just fine. In order to make 
 injectable dll you only have to disable GC (and probably tls), 
 and write otherwise normal D code.


"Normal D code" involves plenty of explicit and implicit 
allocations. The practical and aesthetic considerations of 
hundreds of KB of useless baggage remain.
Jan 23 2014
prev sibling next sibling parent reply "Mike" <none none.com> writes:
On Wednesday, 22 January 2014 at 02:18:43 UTC, Vladimir Panteleev 
wrote:

 Hi,

 What's the current situation of using D without Phobos/Druntime?

 Sometimes, it's quite useful to be able to use D to create tiny 
 EXEs/DLLs. For example, create simple DLL plugins that will be 
 loaded into non-D programs, or even not have a 50-line program 
 take half a meg. Additionally, some tasks require injecting a 
 DLL systemwide (into every running process), so it is critical 
 to minimize the impact by being as unintrusive as possible and 
 having a minimal overhead.

 I've started a "framework" for this purpose a while ago[1], but 
 I heard of people starting similar projects since then and I 
 think they've gotten further than me. Would there be any 
 interest in collaborating and turning this into a community 
 project?


I'm curious, what is your motivation for pursuing this?  What's 
your ultimate objective?
Jan 24 2014
parent reply "Frank Bauer" <y z.com> writes:
D is NOT a systems language. So no point in application level
comparison with C. Set aside syntactic similarities.

If your language does not have the C / C++ *semantics* of new /
delete, or, better yet, owned pointers in Rust that automatically
free their memory when they go out of scope, but instead forces a
GC down your throat for some of the most basic array and standard
library functionality, you will never, ever write kernel level
code that stands a chance against C, C++ or Rust.

Other than that, a "D with owned pointers" and an opt-in GC
relegated to a library implementation (maybe with some minimal
language hooks) would be my language of choice. I love D's
templates.

I understand that this would be a complete redesign of the
language and Phobos, and would break most of the D code out
there. That's why it won't happen.

Everybody seems to realize this, finally. Just have a look at the
Jan 25 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/25/14 2:15 PM, Frank Bauer wrote:

 D is NOT a systems language. So no point in application level
 comparison with C. Set aside syntactic similarities.

 If your language does not have the C / C++ *semantics* of new /
 delete, or, better yet, owned pointers in Rust that automatically
 free their memory when they go out of scope, but instead forces a
 GC down your throat for some of the most basic array and standard
 library functionality, you will never, ever write kernel level
 code that stands a chance against C, C++ or Rust.

 Other than that, a "D with owned pointers" and an opt-in GC
 relegated to a library implementation (maybe with some minimal
 language hooks) would be my language of choice. I love D's
 templates.

 I understand that this would be a complete redesign of the
 language and Phobos, and would break most of the D code out
 there. That's why it won't happen.

 Everybody seems to realize this, finally. Just have a look at the



Wait, what?

Andrei
Jan 25 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 25.01.2014 23:33, schrieb Andrei Alexandrescu:

 On 1/25/14 2:15 PM, Frank Bauer wrote:

 D is NOT a systems language. So no point in application level
 comparison with C. Set aside syntactic similarities.

 If your language does not have the C / C++ *semantics* of new /
 delete, or, better yet, owned pointers in Rust that automatically
 free their memory when they go out of scope, but instead forces a
 GC down your throat for some of the most basic array and standard
 library functionality, you will never, ever write kernel level
 code that stands a chance against C, C++ or Rust.




The guys at Xerox PARC, Swiss Federal Institute of Technology in Zurich,
Cisco, Olivetti seem to think otherwise.

Sadly the industry never cared for their research in programming 
languages and safe OS systems.

--
Paulo
Jan 25 2014
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Saturday, 25 January 2014 at 22:15:29 UTC, Frank Bauer wrote:

 D is NOT a systems language. So no point in application level
 comparison with C. Set aside syntactic similarities.

 If your language does not have the C / C++ *semantics* of new /
 delete, or, better yet, owned pointers in Rust that 
 automatically
 free their memory when they go out of scope, but instead forces 
 a
 GC down your throat for some of the most basic array and 
 standard
 library functionality, you will never, ever write kernel level
 code that stands a chance against C, C++ or Rust.

 Other than that, a "D with owned pointers" and an opt-in GC
 relegated to a library implementation (maybe with some minimal
 language hooks) would be my language of choice. I love D's
 templates.


+1

 I understand that this would be a complete redesign of the
 language and Phobos, and would break most of the D code out
 there. That's why it won't happen.

 Everybody seems to realize this, finally. Just have a look at 
 the

 over.



view of the garbage collector). :/
Jan 25 2014
prev sibling next sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Saturday, 25 January 2014 at 22:15:29 UTC, Frank Bauer wrote:

 D is NOT a systems language. So no point in application level
 comparison with C. Set aside syntactic similarities.


Urgh...


 If your language does not have the C / C++ *semantics* of new /
 delete,


Setting aside syntax, it's extremely trivial to implement 
C++-style new/delete as function templates.


 or, better yet, owned pointers in Rust that automatically
 free their memory when they go out of scope, but instead forces 
 a
 GC down your throat for some of the most basic array and 
 standard
 library functionality,


Array functionality *that C and C++ do not have*. D slices are 
plenty useful without the primitives that allocate, such as 
concatenation. This very thread is an example of how you're not 
forced to use a runtime that implements these primitives.


 Other than that, a "D with owned pointers" and an opt-in GC
 relegated to a library implementation (maybe with some minimal
 language hooks) would be my language of choice. I love D's
 templates.


The GC is a library implementation with language hooks.


 I understand that this would be a complete redesign of the
 language and Phobos, and would break most of the D code out
 there. That's why it won't happen.


There aren't that many language features that depend on a GC, and 
the ones that do can be disabled with a custom runtime.

druntime/Phobos are designed for a mixed allocation strategy, 
where tracing GC is one of the strategies used. Many Phobos types 
and functions do not rely on a GC.


 Everybody seems to realize this, finally. Just have a look at 
 the

 over.




implementation without GC).

D definitely *does*.
Jan 25 2014
next sibling parent "Mike" <none none.com> writes:
On Saturday, 25 January 2014 at 23:01:12 UTC, Jakob Ovrum wrote:

 Setting aside syntax, it's extremely trivial to implement 
 C++-style new/delete as function templates.


I am interested in this.  I am currently using new/destroy.  If 
you know of a way to use templates for this (aside from 
RefCounted and Scoped) please elaborate. It would be quite 
helpful for me.


 The GC is a library implementation with language hooks.


I am implementing a custom runtime and am very interested in this 
as well.  This was the heart of my previous post.  I see that the 
runtime hooks can be used to implement an alternate GC, but do 
you think these hooks could be used to implement a reference 
counted, owned pointer, etc... implementation as an alternative 
to a GC? Are there any currently missing runtime hooks preventing 
such an implementation?

Mike
Jan 25 2014
prev sibling parent reply "Frank Bauer" <y z.com> writes:
On Saturday, 25 January 2014 at 23:01:12 UTC, Jakob Ovrum wrote:

 Setting aside syntax, it's extremely trivial to implement 
 C++-style new/delete as function templates.


Fine. Can I use it with Phobos?


 Array functionality *that C and C++ do not have*. D slices are 
 plenty useful without the primitives that allocate, such as 
 concatenation.


I love D's slices. Super elegant. Can't imagine how one could 
ever invent half slices, i.e. array pointers without length ;)


 This very thread is an example of how you're not forced to use 
 a runtime that implements these primitives.


We must be in two different threads:

On Wednesday, 22 January 2014 at 02:18:43 UTC, Vladimir Panteleev 
wrote:

 - A "standard library" which does not require runtime support, 
 but can also be used when using Druntime (as a GC-free 
 alternative to Phobos)


On Wednesday, 22 January 2014 at 04:13:41 UTC, Mike wrote:

 Phobos will not be useful to me unless I can find some way to 
 make it lighter and GC-Free. ... I would _really_ like to have 
 the
 whole concept of a GC decoupled from D. There are many suitable 
 memory models to use with D, and the memory model seems like it 
 should be a platform feature, not a language feature.


I understand from this thread that we are at a GC-free Hello 
World at this point. Well ...


 The GC is a library implementation with language hooks.


No it is not. It is part of the language. Every allocation 
*inside* the language (i.e. with new) goes through the GC.


 There aren't that many language features that depend on a GC, 
 and the ones that do can be disabled with a custom runtime.


I don't want to miss out on a single language feature of D. Where 
is that GC-free runtime?


 druntime/Phobos are designed for a mixed allocation strategy, 
 where tracing GC is one of the strategies used. Many Phobos 
 types and functions do not rely on a GC.


In theory (which gives me hope), not in practice. Where is that 
GC-free Phobos?



 (disregarding the effort you'd have to go through to get a Java 


 D definitely *does*.


Again, this gives me hope. Please Walter, Andrei: search all the 
forums for "I want D with opt-in GC" (fuzzy search, that is) and 
count matches.
Jan 25 2014
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 26 January 2014 at 02:32:29 UTC, Frank Bauer wrote:

 Fine. Can I use it with Phobos?


Quite a bit of it, actually. There's significant parts of phobos 
which don't do allocation at all: std.algorithm and std.digest 
are two big parts that are pretty good about it.


 No it is not. It is part of the language. Every allocation 
 *inside* the language (i.e. with new) goes through the GC.


Not necessarily, you can change the allocation strategy if you 
want by providing your own function. _d_newclass is a major 
example.

The language sometimes makes tracking the reference really hard, 
for example, getting tho pointer to free with a closure is 
tricky, and tracking temporaries made with the binary concat 
operator. (You could perhaps do it but it would be really easy to 
lose a reference somewhere and leak it, I think binary concat 
should just be left unimplemented if you aren't using the gc (and 
avoided even if you are in any performance critical section)).

So yeah, it is possible to go without the GC with the D language 
by changing runtime functions but the language doesn't help you 
get it *right*.
Jan 25 2014
parent reply "Frank Bauer" <y z.com> writes:
 Adam: thanks for pointing out _d_newclass for me. But for 
classes I would just simply use custom allocators and 
deallocators and use new and delete as in C++.

Leaves dynamic arrays and the rest of Phobos (which parts?) which 
I have to forego if I don't like GC (but I do like slices so 
much, not much left for me to slice then ...). And no, anonymous, 
it's not just reallocating or appending to arrays, every dynamic 
array is allocated on the GC'd heap from the start.

I would really like to have something like Rust's owned pointer 
and refernce semantics in D by default:

Allocation with new gives an *owning pointer* similar to 
std.typecons.Unique, that frees its associated memory 
automatically when it goes out of scope.

Creating a *reference* from an owning pointer gives a 
'non-owning' pointer with no effect on automatic memory 
management whatsoever, but with the compiler-enforced requirement 
that its associated owning pointer can not be mutated as long as 
there are outstanding references in scope. Also the lifetime of a 
reference can not exceed the lifetime of the owning pointer it 
stems from.

This is why even a working 
(http://forum.dlang.org/thread/l96otj$tsj$1 digitalmars.com) 
std.typecons.Unique is not enough. The relationship between 
owning pointers and references needs compiler enforcement.

 Andrei: Short of dumping all GC-dependent language concepts, GC 
collection cycle times are key, no matter how little litter is 
produced. Hope the GC tracing algorithm you are implementing for 
the new custom allocators does not have to chase references too 
deep into the heap. Maybe implementing Rust-style owning pointers 
and references into the core language could turn out to be less 
time-consuming? We could still have GC around as an option a la 
GCollect!MyClass.
Jan 25 2014
parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Sunday, 26 January 2014 at 05:17:35 UTC, Frank Bauer wrote:

  Adam: thanks for pointing out _d_newclass for me. But for 
 classes I would just simply use custom allocators and 
 deallocators and use new and delete as in C++.


Aye, I don't recommend overloading `new` to mean something else. 
Currently `new` = GC allocation, and code can rely on that. 
Better to have such code break (by not defining _d_newclass) than 
silently leak or worse.


 Leaves dynamic arrays and the rest of Phobos (which parts?) 
 which I have to forego if I don't like GC (but I do like slices 
 so much, not much left for me to slice then ...). And no, 
 anonymous, it's not just reallocating or appending to arrays, 
 every dynamic array is allocated on the GC'd heap from the 
 start.


Huh? You can slice any pointer:

---
T[] allocArray(T)(size_t num)
{
     if (auto chunk = cast(T*)calloc(num, T.sizeof))
         return chunk[0 .. num];
     else
         onOutOfMemoryError();
}
---

As well as fixed-length arrays:

---
char[128] buffer = ...;
auto myStackString = buffer[0 .. len];
---

Slices are plenty useful without GC.
Jan 25 2014
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/25/14 6:32 PM, Frank Bauer wrote:

 There aren't that many language features that depend on a GC, and the
 ones that do can be disabled with a custom runtime.


 I don't want to miss out on a single language feature of D. Where is
 that GC-free runtime?


GC is a language feature of D.

As funny as that may seem (as a comeback timed almost too well) this has 
interesting truth to it. Some convenience features of D require GC to 
work, and that's as cut and dried as it gets. Without them, D would need 
to sacrifice some features or complicate the language or concentrate 
focus on that aspect alone (and I suspect Rust is guilty of at least 
some of the above).

You can't have all of D without GC for the simple reason that GC is 
convenient and simplifies things, and often such things are desirable. 
Of course, reducing within reason, modularizing, and compartmentalizing 
the need/use of GC is a goal worth working toward. But all that requires 
reason and measure.


 druntime/Phobos are designed for a mixed allocation strategy, where
 tracing GC is one of the strategies used. Many Phobos types and
 functions do not rely on a GC.


 In theory (which gives me hope), not in practice. Where is that GC-free
 Phobos?




 without GC).

 D definitely *does*.


 Again, this gives me hope. Please Walter, Andrei: search all the forums
 for "I want D with opt-in GC" (fuzzy search, that is) and count matches.


We believe the clamor is overblown. The patterns in which D produces 
garbage (litter, for the most part) are very different from those in 
languages that don't offer a choice. Focusing on library functions that 
produce a few garbage-collected strings when the bulk of the load is 
elsewhere - that's penny wise and pound foolish.

That said, it's good to have control and rein in over how and where 
litter is produced. We see this as an ongoing focus.


Andrei
Jan 25 2014
parent reply "Mike" <none none.com> writes:
On Sunday, 26 January 2014 at 03:29:00 UTC, Andrei Alexandrescu 
wrote:


 GC is a language feature of D.


I hope what you mean is "automatic memory management is a feature 
of D".  I want to clarify my previous statements by saying 
automatic memory management is something that I find attractive 
in D, and something I hope to build in my runtime. But as a rude 
janitor that barges into the party, orders the band to stop 
playing and the dancers to stop moving so he can sweep the floor 
(i.e. GC) ... There must be a better way...and I hope some of you 
will help me find it.

Mike
Jan 26 2014
parent "JR" <zorael gmail.com> writes:
On Sunday, 26 January 2014 at 08:24:55 UTC, Mike wrote:

 ... But as a rude janitor that barges into the party, orders 
 the band to stop playing and the dancers to stop moving so he 
 can sweep the floor (i.e. GC) ...


Nominated for best stop-the-world GC analogy 2014. Cannot unsee. 
(un-think?)
Jan 26 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-01-26 03:32, Frank Bauer wrote:


 I don't want to miss out on a single language feature of D. Where is
 that GC-free runtime?


Here it is: 
https://github.com/D-Programming-Language/druntime/blob/master/src/gcstub/gc.d

It implements the GC API using malloc. One needs to manually delete the 
memory with GC.free.

-- 
/Jacob Carlborg
Jan 26 2014
parent reply "Frank Bauer" <y z.com> writes:
As you heard Andrei, too many *language features*, NOT *user 
code* rely on objects staying around till the GC collects them. 
It's not a matter of malloc/free everything in your user code. D 
as a language would not work with this little gcstub.
Jan 26 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-01-26 16:18, Frank Bauer wrote:

 As you heard Andrei, too many *language features*, NOT *user code* rely
 on objects staying around till the GC collects them. It's not a matter
 of malloc/free everything in your user code. D as a language would not
 work with this little gcstub.


Sure it would, it just wouldn't free everything as it should.

-- 
/Jacob Carlborg
Jan 27 2014
prev sibling next sibling parent reply "anonymous" <anonymous example.com> writes:
On Saturday, 25 January 2014 at 22:15:29 UTC, Frank Bauer wrote:

 D is NOT a systems language. So no point in application level
 comparison with C. Set aside syntactic similarities.

 If your language does not have the C / C++ *semantics* of new /
 delete,


C doesn't have new/delete.


 or, better yet, owned pointers in Rust that automatically
 free their memory when they go out of scope, but instead forces 
 a
 GC down your throat for some of the most basic array


You can do C style array/pointer fiddling in D without the GC. 
You can't new or append, but you can't do that in C either. Seems 
to me, you're comparing more to C++/Rust than to C.


 and standard library functionality,


You have access to C's standard library from D.


 you will never, ever write kernel level
 code that stands a chance against C, C++ or Rust.


Your points don't apply to D vs C.
Jan 25 2014
parent reply "Frank Bauer" <y z.com> writes:
On Saturday, 25 January 2014 at 23:02:44 UTC, anonymous wrote:

 C doesn't have new/delete.


Please read-before-write (non atomic operation): C has the 
*semantics* of new / delete with malloc and free. D has too, if 
you constrain yourself to memory allocation via 
std.c.stdlib.malloc and free, which means no object allocation 
with *new* anymore. We don't want to constrain ourselves to that, 
do we? What we want is malloc/free *semantics* throughout if we 
choose so.


 You can do C style array/pointer fiddling in D without the GC. 
 You can't new or append, but you can't do that in C either. 
 Seems to me, you're comparing more to C++/Rust than to C.



 You have access to C's standard library from D.


I'm aware that I can use a D subset that is roughly equivalent to 
C and C's standard library. This subset is precisely what I am 
*not* talking about. I am talking about all the great modern 
architectural features of D and Phobos.


 Your points don't apply to D vs C.


It does if I want to use D in its entirety not just its subset 
equivalent to C.

So if I want C++ new/delete or Rust's owned pointer semantics I 
should constrain myself to D's subset that is equivalent to C and 
forget about Phobos altogether? Welcome to the *new* D.
Jan 25 2014
next sibling parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Sunday, 26 January 2014 at 02:03:29 UTC, Frank Bauer wrote:

 On Saturday, 25 January 2014 at 23:02:44 UTC, anonymous wrote:

 You have access to C's standard library from D.


 I'm aware that I can use a D subset that is roughly equivalent 
 to C and C's standard library. This subset is precisely what I 
 am *not* talking about. I am talking about all the great modern 
 architectural features of D and Phobos.


You're asking for something to exist right now, which doesn't. 
You want a GC-free minimum runtime which allows use of the 
majority of the language (actually you sound like you want all, 
but that can't happen), and a standard library which can be used 
GC-free. This does not exist and everyone is well aware of it, 
hence the question of this thread "Current state of "D as a 
better C" (Windows)?"

However your initial post claims that the language won't let us 
achieve that state, and people here are trying to explain that 
simply isn't true, we just don't have the libraries built up yet.

Someone needs to take the approach of using D as C, that means 
give up all the nice feature of D and use it as if it were C. 
That person will then need to build out and submit patches to 
bring more of the D language into this "C" world.
Jan 25 2014
parent "Frank Bauer" <y z.com> writes:
On Sunday, 26 January 2014 at 04:18:47 UTC, Jesse Phillips wrote:

 However your initial post claims that the language won't let us 
 achieve that state, and people here are trying to explain that 
 simply isn't true, we just don't have the libraries built up 
 yet.


Wrong. Read one post above:

On Sunday, 26 January 2014 at 03:29:00 UTC, Andrei Alexandrescu 
wrote:

 GC is a language feature of D.

 As funny as that may seem (as a comeback timed almost too well) 
 this has interesting truth to it. Some convenience features of 
 D require GC to work, and that's as cut and dried as it gets.


But I agree with Andrei: it requires reason and measure. I just 
think that D could keep all of the features that make it great 
(modules, templates, slices are without rival, Phobos is well 
laid out), even after a complete overhaul of the memory system. 
Or watch part of the (real) systems programmers move from C++ to 
Rust (should it reach a stable 1.0, it already compiles itself)
Jan 25 2014
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 26.01.2014 03:03, schrieb Frank Bauer:

 On Saturday, 25 January 2014 at 23:02:44 UTC, anonymous wrote:

 C doesn't have new/delete.


 Please read-before-write (non atomic operation): C has the *semantics*
 of new / delete with malloc and free. D has too, if you constrain
 yourself to memory allocation via std.c.stdlib.malloc and free, which
 means no object allocation with *new* anymore. We don't want to
 constrain ourselves to that, do we? What we want is malloc/free
 *semantics* throughout if we choose so.


Whose semantics are those?

Are you aware, that standard malloc/free vary a lot from compiler to 
compiler?

Even generating cascading allocations or deallocations, as they tend to 
use more low level APIs on from the operating system?

Anyone doing high performance computing or games with C ends up creating 
their own allocators anyway.

So I wonder what is this magic performance semantics from malloc/free.

--
Paulo
Jan 25 2014
prev sibling parent "anonymous" <anonymous example.com> writes:
On Sunday, 26 January 2014 at 02:03:29 UTC, Frank Bauer wrote:

 C has the *semantics* of new / delete with malloc and free. D 
 has too, if you constrain yourself to memory allocation via 
 std.c.stdlib.malloc and free, which means no object allocation 
 with *new* anymore. We don't want to constrain ourselves to 
 that, do we? What we want is malloc/free *semantics* throughout 
 if we choose so.


[...]

 I'm aware that I can use a D subset that is roughly equivalent 
 to C and C's standard library. This subset is precisely what I 
 am *not* talking about. I am talking about all the great modern 
 architectural features of D and Phobos.


 Your points don't apply to D vs C.


 It does if I want to use D in its entirety not just its subset 
 equivalent to C.

 So if I want C++ new/delete or Rust's owned pointer semantics I 
 should constrain myself to D's subset that is equivalent to C 
 and forget about Phobos altogether? Welcome to the *new* D.


Welcome to "D as a better C", not "D as a better 'better C' than
C++ and Rust". You might shed a tear for all the goodness you're
missing out on, but there's still templates, slicing, methods,
etc left.
Jan 26 2014
prev sibling parent "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Saturday, 25 January 2014 at 22:15:29 UTC, Frank Bauer wrote:

 D is NOT a systems language. So no point in application level
 comparison with C. Set aside syntactic similarities.

 If your language does not have the C / C++ *semantics* of new /
 delete, or, better yet, owned pointers in Rust that 
 automatically
 free their memory when they go out of scope, but instead forces 
 a
 GC down your throat for some of the most basic array and 
 standard
 library functionality, you will never, ever write kernel level
 code that stands a chance against C, C++ or Rust.

 Other than that, a "D with owned pointers" and an opt-in GC
 relegated to a library implementation (maybe with some minimal
 language hooks) would be my language of choice. I love D's
 templates.

 I understand that this would be a complete redesign of the
 language and Phobos, and would break most of the D code out
 there. That's why it won't happen.

 Everybody seems to realize this, finally. Just have a look at 
 the

 over.


This post made me laugh. Thanks for the entertainment.
Jan 26 2014
prev sibling parent "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Wednesday, 22 January 2014 at 02:18:43 UTC, Vladimir Panteleev 
wrote:

 Hi,

 What's the current situation of using D without Phobos/Druntime?

 Sometimes, it's quite useful to be able to use D to create tiny 
 EXEs/DLLs. For example, create simple DLL plugins that will be 
 loaded into non-D programs, or even not have a 50-line program 
 take half a meg. Additionally, some tasks require injecting a 
 DLL systemwide (into every running process), so it is critical 
 to minimize the impact by being as unintrusive as possible and 
 having a minimal overhead.

 I've started a "framework" for this purpose a while ago[1], but 
 I heard of people starting similar projects since then and I 
 think they've gotten further than me. Would there be any 
 interest in collaborating and turning this into a community 
 project?

 I think some goals would be:
 - A "runtime" (object.d) which provides either stubs for the 
 current compiler hooks, or implementations with minimal 
 dependencies
 - A "standard library" which does not require runtime support, 
 but can also be used when using Druntime (as a GC-free 
 alternative to Phobos)
 - Using MSVCRT on 32-bit as well
 - Options to enable/disable various runtime features? For 
 example, a project may want to use exceptions (which requires 
 ClassInfo) but not the GC.
 - Support for the Unilink linker? I think it is better at 
 generating smaller binaries that OPTLINK.

 There is also some ongoing work on the -betterC switch[2], 
 which I'm quite excited about, but it seems to be currently 
 blocked on waiting for the next DMD release as the changes[3] 
 might break a lot of code.

  [1]: https://github.com/CyberShadow/SlimD
  [2]: https://d.puremagic.com/issues/show_bug.cgi?id=11881
  [3]: https://github.com/D-Programming-Language/dmd/pull/2561


There was a minimal runtime library project somewhere on 
Bitbucket if I remember. I think the goal is the same. You could 
borrow some code from there perhaps.
In general I totally agree with you. I wanted to do the same, but 
decided to wait for allocators...
Jan 26 2014