core.stdcpp

[eles via Digitalmars-d-announce]

On Saturday, 30 August 2014 at 00:01:50 UTC, Mike wrote:
> On Friday, 29 August 2014 at 16:54:18 UTC, Sean Kelly wrote:
>> On Wednesday, 27 August 2014 at 09:43:03 UTC, Mike wrote:
>>> On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright 
>>> wrote:

> I'm judging by both the responses in this thread and the lack 
> of responses in this thread that there isn't support, so I'm 
> fine to go my own way with my ideas if that's what's preferred.

Actuall, I am very much in favor of this, but I admit we are a 
bit in minority. I fel it is not because people ara gainst it, 
but because they feel is not very important. Plus, they have the 
impression that this will involve renaming modules and will need 
modifying curent source code.

It is not about that. Names could remain just as they are, it is 
only about isolating that part of druntime that is really 
critical to run the language. As you defined very well, that part 
that corresponds to java.lang.

There is one thing that bothers me, still, and I did not find the 
appropriate solution to it: if the language defines threads and 
garbage collector, I agree the mechanism for those should go in 
the runtime, but what to do with the function required to handle 
those? For example, creating a thread is done with a function 
(not with a keyword!) and the same goes for the GC.disable(), for 
example.

So, this will kinda break the "runtime means no imports" mantra. 
Or, otherwise, how to do it? C++ fully accepted its dependency on 
stdlib when they wen with Threads, isn't?

I find it uneasy that one accesses the runtime through "import". 
Why we should need that? In C you never import/include something 
for the runtime, nor you have control over it from inside the 
program. It is through compiler params.