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

Reply via email to