What does it bring over modern C++? Why would you want to use it?
D Language accepted for inclusion in GCC
71–80 of 235 posts
Re: D Language accepted for inclusion in GCC
#72Earlier quoted context omitted.
How does this work exactly from a licensing perspective? Will they merge the dmd sources into the gcc tree? Does this mean that the D compiler in gcc will now be GPL(v?) licensed? This is certainly possible since dmd is licensed permissively. https://github.com/dlang/dmd/blob/master/LICENSE.txt I don't mean this to start a fight over licenses I'm just curious how it works when gcc lets other projects in.
I don't see how dmd would be mergable with gcc, completely different backends. gdc however is a different story.
Although the recent DMD backend license change does not affect GDC, GDC is not a complete standalone implementation of a D compiler.
GDC (and LDC, the LLVM D compiler) use the frontend (lexer, parser,semantic) provided by the DMD reference compiler. GDC and LDC then map the AST produced by the frontend to something GCC and LLVM understand.
The DMD frontend has always been boost licensed. So the licensing question is valid here as we'll include boost frontend code into GCC. But I don't really have an answer to the question ;-)
Re: D Language accepted for inclusion in GCC
#73What does it bring over modern C++? Why would you want to use it?
I don't view it's counterpart to be C++ these days; dlang is a GC'd language, so it's actually probably fairer to compare it to Go instead.
Re: D Language accepted for inclusion in GCC
#74This is basically the work of one tireless man; Iain Buclaw. Many thanks to him for putting in so much time and energy into this. It took 6 years from first submission to get it in. Here are the slides from his 2017 DConf talk about the work that went into making this happen: http://dconf.org/2017/talks/buclaw.pdf
Re: D Language accepted for inclusion in GCC
#75Earlier quoted context omitted.
Most useful C++ code is either not templates or it's templates which can be instantiated a finite number of times and then used like non-templated code. Most "header-only"/header-heavy C++ libraries which present the problem you mention solve problems like C++'s smart for loop working like "for x in xs" does in Python but not working like "for x,y in zip(xs,ys)" does or like "for i,x for enumerate(xs)" does etc.; you…
That sounds ..wrong. what about the C++ standard library? Neither vector or sort sounds like that?
Those parts of the C++ standard library are header-only and will be instantiated with concrete types at compile-time.
Re: D Language accepted for inclusion in GCC
#76What does it bring over modern C++? Why would you want to use it?
- Nearly instant compile times
- GC by default, manual memory management where and when you need it with no loss of efficiency
- Better metaprogramming
- Does not compromise on things a C++ coder would care about (speed, efficiency, deterministic behavior, etc.)
The language is led by Andrei Alecsandrescu and Walter Bright, two C++ core language veterans
Re: D Language accepted for inclusion in GCC
#77While I like D and use it for scientific work, wwo "omissions" leave me a bitter taste. Nothrow and Pure are not part of the type signature of functions and consequently the compiler has limited inference about these. However I will keep using it unless something better comes up. C++/C# are not an option for me since I found D.
Re: D Language accepted for inclusion in GCC
#78Earlier quoted context omitted.
Rust has an opt-in garbage collector as a library ( https://docs.rs/gc/ ). I don't know how good it is, though.
What's the use case for a garbage collector in rust?
If you have to share some data across your program and can't determine the lifetime at compilation time, you can't simply rely on the Rust compiler for memory management.
The next option is to use reference counting by wrapping your data in Rc/Arc (depending on whether you need atomicity or not).
But that can still leak memory if you have cyclic data structures and can't break the cycle with Weak pointers.
At this point, what you need is a garbage collector.
Re: D Language accepted for inclusion in GCC
#79Re: D Language accepted for inclusion in GCC
#80I have read many posts saying D was better than C++ as a language but there were no libraries for use case X. Now this may help popularise the language.
D seems like a more useful Rust, or is that completely wrong?
Just more pragmatic, I'd say. D isn't a "big agenda language" (to steal a line from Jonathan Blow). It's extremely multi-paradigm (some might argue to a fault). I think that's why you find people saying D is like C++ or D is like C# or D is like Go or D is like Rust. You get a little taste of everything using D.
Want function programming and purity? Check.
Want C style/low abstraction code? Check.
Want extreme C++ metaprogramming? Check.
Want C#'s LINQ? Check.
Want an improved version of C++'s STL? Check.
Want low cognitive load memory management through a GC? Check.
Want highly tailored memory management? Check.
Want high level object oriented abstractions? Check.
Want memory safety? Check.
Want systems programming? Check.
Want rapid prototyping? Check.
D, fundamentally, assumes the programmer knows what approach they should take and lets them do it. There are no "we know better" design decisions in the language. I think this might be because D is so community driven. With no real company backing D was left in the hands of enthusiasts coming from all sorts of different backgrounds to implement ideas they liked.