core.stdcpp

[Mike via Digitalmars-d-announce]

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:
>>>
>>> The irony is D1 has std.c, and for D2 it was migrated to 
>>> core.stdc.
>>
>> ...and design takes the backseat to convenience.
>
> This was a necessary part of the separation of the runtime
> components of the standard library from the extraneous stuff.
> Consider Druntime to be roughly equivalent to the java.lang
> package.  It contains code and interfaces that pertain to the
> language definition, plus certain related low-level 
> functionality.

I don't believe it was necessary.  D is quite capable of 
implementing the same logic that libc has.  However, if for 
convenience, expediency, time-tested-reliance, optimization, or 
some other reason, one wishes to use libc, they can encapsulate 
it in the platform-specific logic, because that's what it is.

>
> It will always be a judgement call for where to draw the line.
> For example, should Range be in Druntime since it's something 
> the
> compiler is aware of?  What about basic math routines that the
> compiler might replace with an intrinsic call?  So far, we've
> actually erred on the side of having less in Druntime rather 
> than
> more.  It currently contains user-visible code that's actually
> required for every D application: the GC, threads, bit
> operations, and atomics, plus some additional code and
> declarations that are required to implement these features.  And
> that's it.

If D is defined as a garbage-collected language, then it makes 
sense for the GC to be in druntime.  If D is defined as a 
language the intrinsically supports threads, then that belongs in 
druntime, etc...

But D is not defined as a superset of libc, or a standard 
operating system API, so there is no reason to publicly expose 
these.

My argument can be limited to core.stdc/stdcpp for now.
* Only a very limited subset of libc is needed by druntime
* These can be eliminated by implementing them in D, or by using 
what the platform provides (kernel libs, etc...).  It may not be 
convenient/expedient to do so, and will take significant effort 
and testing, but I'm not saying it needs to be done right now, 
just that it should be a goal.
* If it is decided to keep them for convenience/expediency or 
another reason, they can be encapsulated by the ports that need 
them rather than publicly exposed.

D could be so much more than what it currently is.  What I 
eventually would like to see is the following ports:

Architecture (bare metal) ports:
-------------------------------
X86
X86_64
ARM9
ARM7M
MIPS
etc..

OS Ports
--------
Windows
Posix
Linux
MacOS
etc...

I believe that list shows what a narrow focus D currently has.

While a libc exists for all of these, and it might be convenient 
to use it, it is not necessary given D's capabilities.  D could 
do it all, and I think that would set D apart from many other 
languages if it did.

That being said, it certainly would be convenient to make use of 
libc for many of these ports, so let's use it.  Just encapsulate 
it so if, in the future, someone like me wants to submit pull 
requests to gradually remove the dependency on libc, they can do 
so without breaking the API and causing controversy.

>
> You might argue that Druntime shouldn't exist as a separate
> library at all, and at times I've wondered this myself, but some
> of the reasons for this have really borne out in practice, such
> as the forced elimination of unnecessary dependencies.  If you
> look at D1 you'll find that the better part of the standard
> library is linked with every D application because some stuff
> that's always included (the GC code and what's in dmain, for
> example) uses high-level code which in turn depends on 
> everything
> else.  And while it's possible to avoid this with proper
> discipline, this is much easier to accomplish if the code simply
> isn't available in the first place.

I think it is good design to separate the implementation of the 
language spec and compiler intrinsics from library functions that 
implement domain-specific logic or commonly used utility 
functions even if they are considered "low-level".

If one thinks of druntime as a low-level library, there's no 
reason to separate it from phobos.  But if it's thought of as the 
language implementation, as I do, then the reason to separate the 
two is quite apparent, and the boundary between the two is quite 
stark.

>
> When making these arguments, please try thinking about the
> library from the perspective of a library designer and not an 
> end
> user.  Does the standard C interface truly belong in Phobos?  In
> Druntime?  Elsewhere?  Why?  And what factors might influence
> your decision?  Are any of these factors currently present?  
> Some
> of the reasons for the current design are historic and
> unnecessary and others are not.  And anything can be changed if
> someone comes up with a better idea and is willing to do the 
> work
> to make it so.  It sounds like maybe you have a better idea so
> why not submit a pull request demonstrating the solution?

I do have what I believe to be a better solution, and I believe I 
have articulated it, but it needs community support to go 
anywhere.

I must have a different view of druntime than the rest of this 
community.  I believe it should be an implementation of the 
language spec, compiler intrinsics, and encapsulated/isolated 
platform-specific logic.  I don't see it as a low-level library.  
Low-level libraries are just another namespace in phobos.  I 
don't see how one can even define a "low-level library" and that 
is probably why the line between phobos and druntime looks so 
blurry to some.

In this thread, I'm simply trying to avoid having core.stdcpp 
thrown in the druntime when I'm trying to move core.stdc to std.c.

It is wise to first use these forums to check for support first, 
before much time and energy is spent on work that will just be 
rejected.  Take a look at all the work that went into DIP62 and 
how that worked out for the author.

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.

Mike