On Tuesday, 26 August 2014 at 06:35:18 UTC, Walter Bright wrote:
> The implementation of it, however, is going to be ugly and very specific to each C++ compiler. The user shouldn't need to have to see that ugliness, though.

Sounds easier to write your own ::std:: on the c++ side...

On Tuesday, 26 August 2014 at 06:12:54 UTC, Mike wrote:
> On Tuesday, 26 August 2014 at 05:03:01 UTC, Daniel Murphy wrote:
>> "Mike"  wrote in message news:sdrjfagsayomsngmeywp@forum.dlang.org...

> line between the language and the platform.  Make it a more of a language, and less of a framework.

Apparently, all things have this tendency to get bloated. One of the main reasons for C's still unbelievable success is its slimness.

On Tuesday, 26 August 2014 at 07:06:57 UTC, eles wrote:
> Apparently, all things have this tendency to get bloated. One of the main reasons for C's still unbelievable success is its slimness.

Yeah, I think C's success is directly linked to having a clear use scenario and avoiding being a "general purpose language" and having "minimal runtime" as the basic philosophy. With a strong focus on OS development it was locked to it's roots.

C++ was always perceived as more of an application level language, but was sometimes used as a C replacement because of convenient inlining and operator overloading. So people use it without RTTI, exceptions and ::std:: bloat…

I bet D would have been slimmer if it had been part of a OS project, but my gut feeling is that it is more work to slim down D than C++.  I think D would greatly benefit from a high level IR that  various "D dialects" could compile to. Then analyse the high level IR to determine what the runtime requirements are.

On Tuesday, 26 August 2014 at 06:12:54 UTC, Mike wrote:
> The C standard library and C++ standard library are not part of D-the-language.  D would even be better served by putting these features in phobos as std.stdc and std.stdcpp.  This would make them just as conveniently available to users, and reduce the coupling between the language and the platform.

But stdc is its own subpackage in druntime, it's already very modular. It should be easy to remove if you want to create a minimal druntime. For stdcpp, this will be even more true.

Up until now, Phobos consists of mostly high-level modules, while those closer to the OS, and the compiler-dependent parts, reside in druntime. I think this is a good division.

On Tue, 26 Aug 2014 07:00:26 +0000
Ola Fosheim Gr via Digitalmars-d-announce
<digitalmars-d-announce@puremagic.com> wrote:

> On Tuesday, 26 August 2014 at 06:35:18 UTC, Walter Bright wrote:
> > The implementation of it, however, is going to be ugly and very specific to each C++ compiler. The user shouldn't need to have to see that ugliness, though.
>
> Sounds easier to write your own ::std:: on the c++ side...

Quite possibly, but then it wouldn't integrate with existing C++ libraries built with the system's C++ compiler, which would be the point.

- Jonathan M Davis

On Tuesday, 26 August 2014 at 08:25:58 UTC, Jonathan M Davis via Digitalmars-d-announce wrote:
> Quite possibly, but then it wouldn't integrate with existing C++ libraries
> built with the system's C++ compiler, which would be the point.

I know, but the vendor provided C++ libraries could trigger compiler-magic in the optimizer, so it might not be enough to look at the source code in the general case…

On Tuesday, 26 August 2014 at 08:15:07 UTC, Marc Schütz wrote:
> On Tuesday, 26 August 2014 at 06:12:54 UTC, Mike wrote:
>> The C standard library and C++ standard library are not part of D-the-language.  D would even be better served by putting these features in phobos as std.stdc and std.stdcpp.  This would make them just as conveniently available to users, and reduce the coupling between the language and the platform.
>
> But stdc is its own subpackage in druntime, it's already very modular. It should be easy to remove if you want to create a minimal druntime. For stdcpp, this will be even more true.
>
> Up until now, Phobos consists of mostly high-level modules, while those closer to the OS, and the compiler-dependent parts, reside in druntime. I think this is a good division.

My argument isn't about making my own hobby D Runtime.  It's about THE D Runtime and more importantly D-the-language (not library routines and OS bindings).

There's quite a bit in the D Runtime that's not relevant to the language.  I'm guessing it's there because it was convenient at the time.  Take a look at the controversy 11666 caused.  It had nothing to do with the language or it's portability, and everything to do with how to expose the Linux kernel headers.

Just as it is right to separate Phobos from druntime, it is right to separate the language from the platform.  It will ensure D's longevity and our return on investment for learning and contributing to this language.  (You will likely not be programming the platform you're currently programming in 5 years)

I'm not interested in Go, Rust, and other application and server programming languages.  I want an alternative to C/C++ (and I'm not talking about libc, libm, and libcpp, I'm talking about the language).

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.

Mike

On Tuesday, 26 August 2014 at 06:35:18 UTC, Walter Bright wrote:
> On 8/25/2014 11:12 PM, Mike wrote:
>> The C standard library and C++ standard library are not part of D-the-language.
>> D would even be better served by putting these features in phobos as std.stdc
>> and std.stdcpp.  This would make them just as conveniently available to users,
>> and reduce the coupling between the language and the platform.
>
> It's beginning to look more and more like an stdcpp is achievable.
>
> The implementation of it, however, is going to be ugly and very specific to each C++ compiler. The user shouldn't need to have to see that ugliness, though.
>
> It also means that implementing stdcpp is going to require someone who is very willing to go spelunking around the underbelly of C++ ::std:: and understand it, which is a tall order.

You must have stopped reading after my first paragraph :)

I seem to have that effect :(

On Tuesday, 26 August 2014 at 07:56:45 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 26 August 2014 at 07:06:57 UTC, eles wrote:
> Yeah, I think C's success is directly linked to having a clear use scenario and avoiding being a "general purpose language"

What? C is THE quintessential general purpose programming language.  It can be used to program anything.

On Tuesday, 26 August 2014 at 10:44:03 UTC, Mike wrote:
> On Tuesday, 26 August 2014 at 07:56:45 UTC, Ola Fosheim Grøstad wrote:
>> On Tuesday, 26 August 2014 at 07:06:57 UTC, eles wrote:
>> Yeah, I think C's success is directly linked to having a clear use scenario and avoiding being a "general purpose language"
>
> What? C is THE quintessential general purpose programming language.  It can be used to program anything.

Notice the quotes? :)

C can be used to program anything, but it isn't suitable to program everything.