On Tuesday, 26 August 2014 at 19:22:22 UTC, Daniel Murphy wrote:
> "eles"  wrote in message news:qrfucjdbmydvoqgeyybp@forum.dlang.org...

> Apart from the fact that it's too late to change of course.

Well, that separation is just a detail of the implementation, not of the specification. You could simply say that phobos has several namespaces: std, etc, core.

> Druntime and phobos both had c/OS bindings at some point (core.stdc + std.c) but duplication is bad, so they were/are being moved into druntime.

The question of dupplication may be addressed now better, since the newly fixed bug about hierarchical packaging.

> In druntime you have the true, hidden runtime code (startup, profiler, coverage, unittesting, AAs), plus core language stuff (GC, Thread (+core.time)).

_only that_ should be the runtime. And the sole part that one needs to port in order to claim having a full port of the D language (that is, the compiler). These are the tires of the cars, the things that touch the ground. Everything else is optional. (Pirelli had a nice advertisemnt with this line)

And, to go further, only c/OS bindings required for this are to be embedded at this level.

> Phobos is supposed to be 100% optional, although it isn't, quite.  If you don't want to use phobos, for example if you are automatically porting a large C++ application, it's nice to simply ban phobos and have that clear distinction.

Phobos shall be 100% optional, otherwise you don't have a language, but a framework. This is the separation line: the runtime is a must for the language, the standard library is not. If in doubt wether one piece belongs, cut here.

On Tuesday, 26 August 2014 at 18:28:38 UTC, Andrei Alexandrescu wrote:

> I don't understand the objection. Are you arguing that we shouldn't make core.stdc and core.stdcpp available, and instead let anyone who wants to use libc and libc++ write their own declarations?

No. We currently have std.c and core.stdc.  I believe core.stdc should be migrated to std.c, not the other way around.  And before we make the same mistake with core.stdcpp, we should set a new precedent with std.cpp instead.

"Why?"  D is not subset of C.  D is not defined in C.  It is its own autonomous language (at least I though it was).  Therefore, the dependencies on libc are artificial.  Let's not add another artificial dependency with core.stdcpp.  The OS bindings in core.sys are another artificial dependency, but let's not go there right now.

"But druntime relies on libc?"  Wrong! Some of the code needed to port druntime to certain platforms relies on libc (and actually doesn't need to).  This code should be encapsulated and isolated from other ports, not publicly exposed and conflated with the rest of the language implementation.  This is in the spirit of issue 11666.

I believe druntime's scope should be reduced to simply implementing the language, not creating an OS or library API.  That's what phobos and DUB are for.

I'm asking this community to consider setting a new precedent for druntime:  reduce the scope to just the language implementation, encapsulate and isolate the platform specific logic (e.g. the ports - see 11666), and deport the artificial dependencies to phobos or other libraries.

Mike

On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote:

> I'm asking this community to consider setting a new precedent for druntime:  reduce the scope to just the language implementation, encapsulate and isolate the platform specific logic (e.g. the ports - see 11666), and deport the artificial dependencies to phobos or other libraries.
>

... and start by creating std.cpp instead of core.stdcpp.

On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote:
> I believe druntime's scope should be reduced to simply implementing the language, not creating an OS or library API.  That's what phobos and DUB are for.
>
> I'm asking this community to consider setting a new precedent for druntime:  reduce the scope to just the language implementation, encapsulate and isolate the platform specific logic (e.g. the ports - see 11666), and deport the artificial dependencies to phobos or other libraries.

What do you think about following compromise:

1) C bindings are defined in spec to be optional
2) They are still kept in druntime repo but declared an implementation detail
3) C bindings are defined to be mandatory in Phobos - if Phobos is used with druntime that does not provide C bindings, it must expose ones of its own.

It effectively keeps existing layout but moves from a specification to implementation detail making binding-free druntime 100% legal D implementation.

On Tuesday, 26 August 2014 at 14:48:48 UTC, Andrei Alexandrescu
wrote:
> On 8/26/14, 3:06 AM, Mike wrote:
>> D has a lot of potential beyond it's current use.  Please take this
>> opportunity to reflect on what's been done, take a look ahead, and see
>> if we can set a better precedent for the future.
>
> C++ interoperability is very important for D's future. -- Andrei

I think this cannot be understated. People have existing codebase
that they aren't going to rewrite from scratch.

On Wednesday, 27 August 2014 at 01:05:19 UTC, Dicebot wrote:
> On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote:
>> I believe druntime's scope should be reduced to simply implementing the language, not creating an OS or library API.  That's what phobos and DUB are for.
>>
>> I'm asking this community to consider setting a new precedent for druntime:  reduce the scope to just the language implementation, encapsulate and isolate the platform specific logic (e.g. the ports - see 11666), and deport the artificial dependencies to phobos or other libraries.
>
> What do you think about following compromise:
>
> 1) C bindings are defined in spec to be optional
> 2) They are still kept in druntime repo but declared an implementation detail
> 3) C bindings are defined to be mandatory in Phobos - if Phobos is used with druntime that does not provide C bindings, it must expose ones of its own.
>
> It effectively keeps existing layout but moves from a specification to implementation detail making binding-free druntime 100% legal D implementation.

By "C bindings" do you really mean "C/C++ bindings" given the context of this thread?

On Wednesday, 27 August 2014 at 01:57:38 UTC, Mike wrote:
>> What do you think about following compromise:
>>
>> 1) C bindings are defined in spec to be optional
>> 2) They are still kept in druntime repo but declared an implementation detail
>> 3) C bindings are defined to be mandatory in Phobos - if Phobos is used with druntime that does not provide C bindings, it must expose ones of its own.
>>
>> It effectively keeps existing layout but moves from a specification to implementation detail making binding-free druntime 100% legal D implementation.
>
> By "C bindings" do you really mean "C/C++ bindings" given the context of this thread?

Yeah, "any external / OS bindings" is probably more appropriate wording.

On Wednesday, 27 August 2014 at 01:21:59 UTC, deadalnix wrote:
> I think this cannot be understated. People have existing codebase
> that they aren't going to rewrite from scratch.

PS: This is the reason why SDC unwind C++'s exception properly
(but you obviously can't catch them).

On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote:
>
> I'm asking this community to consider setting a new precedent for druntime:  reduce the scope to just the language implementation, encapsulate and isolate the platform specific logic (e.g. the ports - see 11666), and deport the artificial dependencies to phobos or other libraries.
>

Please understand that I'm not suggesting we start refactoring druntime for 2.067.  All I'm asking for is that we recognize that C/C++ library and OS bindings don't belong in druntime as public modules, and we gradually work towards migrating them to phobos or some other library in the years to come.

Since C++ language bindings are a new addition, let's not exacerbate the problem by putting it in druntime as core.stdcpp, but set a new precedent by putting them in std.cpp (or core.stdcpp in phobos, or whatever else you have in mind).

Mike

On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote:
> On Tuesday, 26 August 2014 at 18:28:38 UTC, Andrei Alexandrescu wrote:

> No. We currently have std.c and core.stdc.

Let's not even say this is confusing.