core.stdcpp

[eles via Digitalmars-d-announce]

On Tuesday, 26 August 2014 at 18:33:07 UTC, Daniel Murphy wrote:
> "Mike"  wrote in message 
> news:bkkdiikafdsraqssjndv at forum.dlang.org...
>
>> > I really don't see a practical problem with having them in 
>> > druntime, only a philosophical one.
>>
>> It give the impression that D requires the C standard library, 
>> the C++ standard library, and an full-featured desktop OS in 
>> order to function. If I create a port without core.stdc, it 
>> can be argued that my port is incomplete.  Well I argue that 
>> my port is a complete implementation of the language and 
>> core.stdc is not part of the D language.
>
> What platform supports threads and GC but doesn't have a C lib 
> available?  I certainly would argue that this hypothetical port 
> is incomplete, not because druntime including bindings to libc 
> declares it part of the language, but because I can't see a 
> good reason not to include them.
>
>> Then they can be put in their own library instead of phobos.
>
> Yes, they could.  IMO the downsides of having to maintain a 
> third library outweighs the 'correctness' advantage, or even 
> having a different root package for this stuff.  And there is 
> no way it's ever going to change at this point.
>
>> That's even better as far as I'm concerned.  GTKD isn't part 
>> of phobos or druntime.  I don't see libc as being any 
>> different (in principle) than GTKD.
>
> Druntime doesn't use GTK, so it is different.  The inclusion of 
> C/OS bindings is historical, and not worth changing.
>
>> > and they are used in druntime internally.
>>
>> For a practical implementation, those ports that have a libc 
>> can make use of it, but it should be internal, and isolated 
>> from the language implementation and the other ports, as is 
>> the spirit of 11666.
>
> There is no point as the bindings are already in druntime and 
> there is very little chance that is going to change.
>
>> But you could take it a step further for the principled 
>> approach. Implement those few features of libc that are needed 
>> by the druntime in D, and earn some bragging rights.
>
> You could, but it has very little practical value.  I 
> personally wouldn't waste my time bragging to someone who 
> thinks druntime depending on libc is an argument against D.
>
>> Why create DDMD?  We already have an implementation in C++, 
>> right.  What a waste of time... (of course I'm being 
>> facetious.  Forgive me, but I think it's a great example of 
>> why we should do something in D even though a C/C++ 
>> implementation exists.  No offense intended)
>
> It's possible you missed the point of DDMD.  DMD is an actively 
> developed codebase which can benefit from many of the features 
> D offers.  Well, that was my motivation anyway.  I know other 
> people got excited by the idea for other reasons.
>
> There is no practical advantage (to the project) from 
> converting a fully debugged, optimized application or library 
> to another language, unless the language barrier is preventing 
> interop.  A libc written in D would not give us anything of 
> practical value.
>
>> That's exactly my point.  The debate that ensued with 11666 
>> had nothing to do with the spirit of 11666.  If those OS 
>> bindings weren't in druntime, 11666 would already be 
>> implemented without controversy.  And we'd likely already have 
>> a few more ports of D to other platforms.  The 11666 debate 
>> belongs in a std.linux debate or a liblinux debate or some 
>> other OS API port debate.
>
> No, the exact same thing would have happened if they were in a 
> different package/repository.  A different root package would 
> not change the contributors or contribution process.
>
>> Publicly exposing core.stdc and the OS bindings in druntime is 
>> getting in the way of bringing D to more platforms, and the 
>> 11666 debate demonstrates that.
>
> This is just nonsense.  Changing the root package changes 
> nothing.
>
>> Or those features in libc could be implemented in D, removing 
>> the artificial dependency on libc.
>
> Re-implementing debugged and optimized code is a waste of time.
>
>> Only the *port* should have bindings to libc.  The language 
>> implementation should not.  Again those bindings should be 
>> encapsulated in the port, not publicly exposed as part of the 
>> D language.
>
> 1) Being part of druntime does not automatically mean something 
> HAS to be available on every platform.  eg the windows bindings 
> are not available on non-windows
> 2) I don't see any point in not exposing the c lib from 
> druntime, nor do I see any platform where that would be a 
> problem that does not have much more serious issues with 
> hosting D.
>
>> * It conflates the language with the platform. druntime should 
>> be solely the implementation of the language, not an OS API.
>
> I disagree, having the OS API in druntime is great and not a 
> problem.
>
>> * It conflates the implementation of the language with 
>> bindings for external libraries.
>
> C interop is part of D.  Low level (direct) access to operating 
> system APIs is part of D.  Exposing them is useful.
>
>> Again, druntime is the language implementation, not an 
>> application programming framework.
>
> By this logic the C lib header files and windows.h files make 
> an application programming framework.
>
>> * It sets the wrong precedent for a systems programming 
>> language. IMO a true systems programming language should be 
>> self-reliant.  That is, it should be a language that can be 
>> used to build the first layer of hardware abstraction.
>
> D can be used for that.  But realistically, this is a 
> constrained environment which will use a custom druntime, and 
> be restricted to a subset of D.
>
>> * It creates artificial dependencies when there's no real 
>> dependency.  C++ being a superset of C is an example of a real 
>> dependency.  That is not D.
>
> I don't consider this to be a problem worth worrying about.
>
>> * It gets in the way of porting the language to more platforms 
>> and complicates maintenance of the runtime. Case in point: the 
>> 11666 debate.
>
> No, it doesn't.  Even if these bindings weren't in druntime, 
> they'd be in another official library.  Nothing would be 
> different with respect to 11666.
>
>> * It makes D unportable to some platforms without creating 
>> their own dialect of the language or their own D runtime 
>> implementation
>
> I expect D is already unportable to these platforms without 
> doing these things.  Removing libc bindings would not change 
> this.
>
>> In summary, I believe libc, libstd++, and the OS bindings 
>> should be encapsulated and isolated by the ports that need 
>> them, not publicly exposed as part of the D language 
>> implementation.  Having bindings to these these libraries is 
>> super important, and I'm glad they exists.  I just don't think 
>> they belong in the D language implementation, except as 
>> encapsulated, isolated artifacts of ports that need them.
>
> In an ideal world, the bindings would be more cleanly separated 
> from other runtime stuff.  But they're not.  It would require a 
> very compelling argument to move them now, and this really 
> isn't it.
>
> We could document that core.stdc is not a required part of a D 
> implementation, but it should be trivial to provide on any 
> platform that can support a complete the rest of D, so there 
> doesn't seem to be any point.

While this might be acceptable, there is one more question: what 
use to have the druntime separated from phobos, in this case?

For me the druntime shall include only the runtime components 
that are required for a program to function and on which one 
could build the whole standard library. And that would be: 
handling the arguments, the GC, basically, the D program 
execution model. And by D here I mean "the language", not the 
"batteries included".