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