core.stdcpp

[via Digitalmars-d-announce]

On Saturday, 30 August 2014 at 08:39:12 UTC, eles wrote:
> 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.

For the record: This describes my stance, too. I acknowledge that 
it would be cleaner to separate the C bindings in a dedicated 
package outside of druntime (though druntime could then import 
this library instead of keeping its own copy of some bindings 
around). This package could then contain bindings to higher-level 
libraries, too. I just don't see it as a pressing issue, nor are 
there obvious disadvantages to the current situation, from what I 
can tell.

> 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 don't agree with this mantra, however. It makes sense for 
internally used functions like _d_throw, but it is fully 
acceptable IMO to treat some modules under core.* as part of the 
language that have to be imported when required.

>
> 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.

There are some very low-level things for which you have to 
include header files. varargs for one, setjmp/longjmp, exit()... 
I would argue that these are parts of the language that happen to 
be implemented in the standard library (I don't know how exactly 
the specification treats them, however).