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:

> convenient inlining and operator overloading. So people use it

For me, what it would be really nice to have in C from C++ would be templates.
And from D, that scope().

> 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.

The problem with starting designing (and implementing) frameworks instead of languages is that you have to keep up with everything and to never cease expanding. New needs will appear, new paradigms (platforms, distributed systems and so on) and you will have to play the game.

It is OK to provide extensive standard library, but not put too much into the language (and, for me, the druntime shall be seen as part of the language, not of the framework).

But, still. Even Java and C# have a separation between the language and the framework, more than, for example, Go has.

On Tuesday, 26 August 2014 at 10:57:10 UTC, eles wrote:
> For me, what it would be really nice to have in C from C++ would be templates.
> And from D, that scope().

When I think about it, I think one of the reasons for going from C to C++ in visualization/games was that 3D operations in C are unreadable. With operator overloading it got better.

Of course, the C compiler could just have been extended with basic arithmetic operators on fixed size arrays… and added SIMDy alignment.

I think C was a little late with adding needed features, that gave C++ room for marketing itself.

> The problem with starting designing (and implementing) frameworks instead of languages is that you have to keep up with everything and to never cease expanding. New needs will appear, new paradigms (platforms, distributed systems and so on) and you will have to play the game.

Yep, that is true.

> It is OK to provide extensive standard library, but not put too much into the language (and, for me, the druntime shall be seen as part of the language, not of the framework).

The problem is that once you go for RTTI and GC then the runtime is already quite big, so adding one piece to it does not seem like a big deal…

I think a language like D is best suited for things that can be resolved at compile time than the more dynamic stuff.

I'd rather see whole program analysis and as much static features as possible than all the dynamic aspects and the runtime requirements that come with it…

That would give the project more focus and make it more suitable for real system level programming.

> But, still. Even Java and C# have a separation between the language and the framework, more than, for example, Go has.

Yes, they compile to a medium level IR.

"Ola Fosheim Grøstad" " wrote in message news:pbfaphgiugafrhachewl@forum.dlang.org...

> 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…

I would be very surprised to find a C++ compiler that does this over public function boundaries, as it would prevent mixing optimized and unoptimized code. 

"Mike"  wrote in message news:zjscnxerhbxnopvayxjh@forum.dlang.org...

> 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.

I really don't see a practical problem with having them in druntime, only a philosophical one.  They should still be available when not using phobos, and they are used in druntime internally.

> I think this is what makes issue 11666[1] so difficult and controversial. The features of the C std lib that are needed by the D runtime are not many, and could be re-implemented in D. The OS bindings needed to implement the D runtime could be internal and moved to a separate folder as proposed in the spirit of 11666.  Public OS bindings could be put in std.linux, std.windows, etc... along with std.stdc and std.stdcpp.

11666 is contentious because everybody has a different opinion on the layout.  This is about personal preferences, and has nothing to do with OS bindings being in druntime.  The same exact discussion would happen if they were in phobos.

> It might be expeditious to just wrap and link, but I argue that D would be more appealing as a language (rather than a framework) if this wasn't the case.

I get that you're saying this, but why?  How will it make any difference to anything ever?  libc is ubiquitous, and the parts that are used internally could trivially be reimplemented on a platform where it was missing.  (or more likely, it could just be ported)

> I concede this is true for the vast majority of systems out there, but it makes D an applications programming framework, not a systems programming language.

???????????  If you want to / need to, you can write a libc implementation in D.  The fact that the major D platforms all choose to link against the system libc instead of rolling their own has no bearing on the language class of D.  The fact that druntime includes a prototype for memcpy or fopen does not change anything either.  It just makes D more convenient for porting C code.

> I politely ask those pursuing core.stdcpp to reconsider and look further in the future.  Please think beyond desktop and server application programming.  Consider what D could be used for, not just what it is currently used for, and darken the line between the language and the platform.  Make it a more of a language, and less of a framework.

It could be my failing, but I really don't see the point.  What are the potential consequences of maintaining and extending the C, C++ and OS bindings in druntime? 

On Tuesday, 26 August 2014 at 12:23:18 UTC, Daniel Murphy wrote:
> I would be very surprised to find a C++ compiler that does this over public function boundaries, as it would prevent mixing optimized and unoptimized code.

Probably, at least without whole-program optimization turned on.

But you still have to track compiler version changelogs and then deal with possibly multiple D implementations just fro one compiler. I guess it can work out if you limit yourselves to just std::vector and std::string…

This idea would have a more merit if DMD was 100% LLVM based and focused on one architecture… Doing this for many compilers on many architectures sounds like versioning hell.

"Ola Fosheim Grøstad" " wrote in message news:mclztlymyjydwhcxsepk@forum.dlang.org...

> Probably, at least without whole-program optimization turned on.

Linking with D is not a concern for whole-program-optimized C++ programs.

> But you still have to track compiler version changelogs and then deal with possibly multiple D implementations just fro one compiler. I guess it can work out if you limit yourselves to just std::vector and std::string…

Yes, it's a pain.  I've done it with one templated struct inside DDMD, and that was a pain.  I don't know if it will work sufficiently for mapping to stl, but it's worth a try.

It's usually easier to test with multiple versions and manually determine differences when problems arise.  Changelogs often do not cover anything more than API changes, especially with some vendors.

> This idea would have a more merit if DMD was 100% LLVM based and focused on one architecture… Doing this for many compilers on many architectures sounds like versioning hell.

It would be easier, but I don't think it changes the merit of the idea. Matching calling conventions is a much more difficult problem (in dmd's backend at least) and yet interoperability is so useful that it's worthwhile. 

On Friday, 22 August 2014 at 21:41:13 UTC, Andrew Edwards wrote:
> On 8/23/14, 3:33 AM, Andrei Alexandrescu wrote:
>> On 8/22/14, 10:05 AM, John Colvin wrote:
>>> As I'm sure has been mentioned elsewhere, the website changes should be
>>> part of the release process, not an afterthought.
>>
>> Agreed. Who would like to volunteer being our webmaster? We'll discuss
>> with our admin to give push rights. -- Andrei
>>
>
> As I mentioned in an earlier post in this thread, I need access. I did the update for every beta/RC. This one was not an oversight, I intentionally did not update the page. Given the right to push the update, I will, But I'm not going to sit around creating pull requests for one a line delete or one character edit and the wait 24hour+ for it to be published before I can proceed with what I'm doing.
>
> Then again, if that's required is a cronjob as Brad has suggested, then I guess the problem is solved.

I was waiting few days for someone to update the main page before I lost patience and created the pull-request. Even worse - it was not accepted until I explicitly asked Andrej to merge it on IRC...

This said I am afraid I will have to agree with conclusion that our release manager will have to push the change of the main page with updated details, after each release.

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

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 know it is and I fully support it.  I'm not arguing against it.  Please add all C++ interoperability support you want to the compiler and to druntime.  I look forward to making use of it.

But libstdc++ is not part of C++-the-language, and libc is not part of C-the-language.  C and C++ can be used without them; I do every day.

If core.stdcpp is intended to be the language bindings to libstdc++, I don't think it should belong it D's language implementation, druntime, any more the language bindings to Cairo or GTK should.

The same goes for core.stdc and core.sys.linux and friends, as these are not part of D's language implementation.

Mike

On Tuesday, 26 August 2014 at 15:30:35 UTC, Mike wrote:
> On Tuesday, 26 August 2014 at 14:48:48 UTC, Andrei Alexandrescu wrote:
>> On 8/26/14, 3:06 AM, Mike wrote:

> The same goes for core.stdc and core.sys.linux and friends, as these are not part of D's language implementation.

Am I correct to define the language as:

--------begin file---------------
//no imports here

//any code here
---------------------------------

?

If you import, then is the library.