core.stdcpp
eles via Digitalmars-d-announce
digitalmars-d-announce at puremagic.com
Sat Aug 30 01:39:10 PDT 2014
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.
More information about the Digitalmars-d-announce
mailing list