What are the worst parts of D?

[Tofu Ninja via Digitalmars-d]

There was a recent video[1] by Jonathan Blow about what he would
want in a programming language designed specifically for game
development. Go, Rust, and D were mentioned and his reason for
not wanting to use D is is that it is "too much like C++"
although he does not really go into it much and it was a very
small part of the video it still brings up some questions.

What I am curious is what are the worst parts of D? What sort of
things would be done differently if we could start over or if we
were designing a D3? I am not asking to try and bash D but
because it is helpful to know what's bad as well as good.

I will start off...
GC by default is a big sore point that everyone brings up
"is" expressions are pretty wonky
Libraries could definitely be split up better

What do you think are the worst parts of D?

[1]

[Ola Fosheim Grostad via Digitalmars-d]

Post by Tofu Ninja via Digitalmars-d
What do you think are the worst parts of D?

1. The whining in the forums.

2. Lacks focus on a dedicated application area.

3. No strategy for getting more people on board.

4. No visible roadmap.

5. Too much focus on retaining C semantics (go does a bit better)

6. Inconsistencies and hacks (too many low hanging fruits)

7. More hacks are being added rather than removing existing ones.

8. Not enough performance oriented process.

9. It's mysteriously addictive and annoying at the same time.

10. It's contagious and now I'm in bed with a cold.

[Tofu Ninja via Digitalmars-d]

On Saturday, 20 September 2014 at 13:30:24 UTC, Ola Fosheim

On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja

Post by Tofu Ninja via Digitalmars-d
What do you think are the worst parts of D?

1. The whining in the forums.
2. Lacks focus on a dedicated application area.
3. No strategy for getting more people on board.
4. No visible roadmap.

Not really a problem with the language. Just problems.

5. Too much focus on retaining C semantics (go does a bit
better)
6. Inconsistencies and hacks (too many low hanging fruits)
7. More hacks are being added rather than removing existing
ones.

Definitely can agree, I think it has to do with the sentiment
that it is "too much like C++"

8. Not enough performance oriented process.

Not sure what you are saying, are you saying there is not a big
enough focus on performance?

9. It's mysteriously addictive and annoying at the same time.

Is that a problem?

10. It's contagious and now I'm in bed with a cold.

:<

[via Digitalmars-d]

Post by Tofu Ninja via Digitalmars-d
Not really a problem with the language. Just problems.

It is kind of interlinked in a world that keeps moving forward. I
found myself agreeing (or at least empathising) with a lot of
what Jonathan Blow said. Of course, since his presentation was
laid-back the people on reddit kind of attacked him and who
knows, maybe he lost inspiration. He did at least respond on
twitter. And his language project probably depends on his next
game Witness (which sounds cool) to succeed.

Anyway, I think he got the right take on it, reach out to other
devs in his own sector and ask them about their practice, then
tailor a language with little syntactical overhead for that use
scenario. Of course, it won't fly if he doesn't manage to attract
people who are more into the semantics of computer languages, but
I root for him anyway. I like his attitude.

On a related note I also read somewhere that Carmack is looking
at GC for the gameplay data. Basically only a heap scanning, but
compacting GC, that can run per frame. Seems the game logic
usually fits in 5MB, so it might work.

Post by Tofu Ninja via Digitalmars-d
Definitely can agree, I think it has to do with the sentiment
that it is "too much like C++"

Yes, I think Jonathan got that part right. I guess also that any
kind of "unique traits" that feels like "inventions" will be
eagerly picked up and hold up as good ideas by enthusiasts. Even
if they are just special cases of more general constructs or
variations of existing concepts posing under a new name. Perhaps
an important aspect of the sociology of computer languages.
(Lispers tend to be terribly proud of their language of choice :)

Post by Tofu Ninja via Digitalmars-d

Post by Ola Fosheim Grostad via Digitalmars-d
8. Not enough performance oriented process.

Not sure what you are saying, are you saying there is not a big
enough focus on performance?

I think there is too much focus on features both in language and
library. I'd personally prefer smaller and more benchmark
focused. It is better to be very good at something limited, IMO.

I also think that the big win in the coming years come for the
language that most successfully can make elegant low overhead
access to SIMD instructions without having to resort to
intrinsics. I have no idea what the syntax would be, but that
seems to be the most promising area of language design in terms
of performance IMO.

[via Digitalmars-d]

Jonathan Blow has expressed himself about D before


http://www.kotaku.com.au/2012/05/most-popular-video-games-are-dumb-can-we-stop-apologising-for-them-now/

It could be incidental, of course.

[AsmMan via Digitalmars-d]

Post by Tofu Ninja via Digitalmars-d
On Saturday, 20 September 2014 at 13:30:24 UTC, Ola Fosheim

On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja

Post by Tofu Ninja via Digitalmars-d
What do you think are the worst parts of D?

1. The whining in the forums.
2. Lacks focus on a dedicated application area.
3. No strategy for getting more people on board.
4. No visible roadmap.

Not really a problem with the language. Just problems.

5. Too much focus on retaining C semantics (go does a bit
better)
6. Inconsistencies and hacks (too many low hanging fruits)
7. More hacks are being added rather than removing existing
ones.

Definitely can agree, I think it has to do with the sentiment
that it is "too much like C++"

It's really needed to keep C++-compatible as possible otherwise
too few people are going to use it. If C++ wasn't C-compatible do
you think it would be a successfully language it is today? I
don't think so.

[ketmar via Digitalmars-d]

On Mon, 22 Sep 2014 14:28:47 +0000

Post by AsmMan via Digitalmars-d
It's really needed to keep C++-compatible as possible otherwise
too few people are going to use it. If C++ wasn't C-compatible do
you think it would be a successfully language it is today? I
don't think so.

D is not c++-compatible anyway. and talking about compatibility: it's
what made c++ such a monster. if someone wants c++ he knows where to
download c++ compiler.

the last thing D should look at is c++.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140922/c4c8139b/attachment.sig>

[Andrei Alexandrescu via Digitalmars-d]

Post by ketmar via Digitalmars-d
On Mon, 22 Sep 2014 14:28:47 +0000

Post by AsmMan via Digitalmars-d
It's really needed to keep C++-compatible as possible otherwise
too few people are going to use it. If C++ wasn't C-compatible do
you think it would be a successfully language it is today? I
don't think so.

D is not c++-compatible anyway.

D is ABI- and mangling-compatible with C++.

Post by ketmar via Digitalmars-d
and talking about compatibility: it's
what made c++ such a monster. if someone wants c++ he knows where to
download c++ compiler.
the last thing D should look at is c++.

Well what can I say? I'm glad you're not making the decisions.


Andrei

[ketmar via Digitalmars-d]

On Mon, 22 Sep 2014 16:14:28 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d at puremagic.com>

Post by Andrei Alexandrescu via Digitalmars-d

Post by ketmar via Digitalmars-d
D is not c++-compatible anyway.

D is ABI- and mangling-compatible with C++.

but we were talking about syntactic compatibility.

Post by Andrei Alexandrescu via Digitalmars-d
Well what can I say? I'm glad you're not making the decisions.

i HATE c++. i want it to DIE, to disappear completely, with all the
code written in it. so yes, it's good to D that i can't freely mess
with mainline codebase. 'cause the first thing i'll do with it is
destroying any traces of c++ interop. the world will be a better place
without c++.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140923/bb4bdb41/attachment.sig>

[H. S. Teoh via Digitalmars-d]

Post by ketmar via Digitalmars-d
On Mon, 22 Sep 2014 16:14:28 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d at puremagic.com>

Post by Andrei Alexandrescu via Digitalmars-d

Post by ketmar via Digitalmars-d
D is not c++-compatible anyway.

D is ABI- and mangling-compatible with C++.

but we were talking about syntactic compatibility.

Post by Andrei Alexandrescu via Digitalmars-d
Well what can I say? I'm glad you're not making the decisions.

i HATE c++. i want it to DIE, to disappear completely, with all the
code written in it. so yes, it's good to D that i can't freely mess
with mainline codebase. 'cause the first thing i'll do with it is
destroying any traces of c++ interop. the world will be a better place
without c++.

For a moment, I read that as you'll destroy any traces of C++, so the
first thing that would go is the DMD source code. :-P


T

[ketmar via Digitalmars-d]

On Mon, 22 Sep 2014 19:16:27 -0700

Post by H. S. Teoh via Digitalmars-d
For a moment, I read that as you'll destroy any traces of C++, so the
first thing that would go is the DMD source code. :-P

but we have magicport! well, almost... i'll postpone c++ destruction
until magicport will be complete and working. ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140923/b66cf18a/attachment-0001.sig>

[deadalnix via Digitalmars-d]

On Tuesday, 23 September 2014 at 01:39:00 UTC, ketmar via

Post by ketmar via Digitalmars-d
On Mon, 22 Sep 2014 16:14:28 -0700
Andrei Alexandrescu via Digitalmars-d
<digitalmars-d at puremagic.com>

Post by Andrei Alexandrescu via Digitalmars-d

Post by ketmar via Digitalmars-d
D is not c++-compatible anyway.

D is ABI- and mangling-compatible with C++.

but we were talking about syntactic compatibility.

Post by Andrei Alexandrescu via Digitalmars-d
Well what can I say? I'm glad you're not making the decisions.

i HATE c++. i want it to DIE, to disappear completely, with all
the
code written in it. so yes, it's good to D that i can't freely
mess
with mainline codebase. 'cause the first thing i'll do with it
is
destroying any traces of c++ interop. the world will be a
better place
without c++.

If you hate C++, you shouldn't have too much trouble to
understand that offering a way out for people using C++ is key.

[ketmar via Digitalmars-d]

On Tue, 23 Sep 2014 01:45:31 +0000

Post by deadalnix via Digitalmars-d
If you hate C++, you shouldn't have too much trouble to
understand that offering a way out for people using C++ is key.

but there is! D is perfectly able to replace c++.

ah, i know, there is alot of legacy c++ code and people can't just
rewrite it in D. so... so bad for that people then.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140923/e55e2fbb/attachment.sig>

[Sean Kelly via Digitalmars-d]

The lack of clear direction or communication thereof. A
continual adding of new stuff to try and appease the theoretical
masses who will certainly come flocking to D if implemented, and
a lack of attention paid to tightening up what we've already got
and deprecating old stuff that no one wants any more. And
inconsistency in how things work in the language. Oh, and
function attributes. I'm sure someone likes them, but I'm
drowning in pure system const immutable @nogc @illegitemate @wtf
hell.

[Andrei Alexandrescu via Digitalmars-d]

Post by Sean Kelly via Digitalmars-d
The lack of clear direction or communication thereof.

* C++ compatibility
* Everything GC-related

Probably a distant third is improving build tooling. But those two are
more important that everything else by an order of magnitude.


Andrei

[Sean Kelly via Digitalmars-d]

On Tuesday, 23 September 2014 at 15:47:21 UTC, Andrei

Post by Andrei Alexandrescu via Digitalmars-d

Post by Sean Kelly via Digitalmars-d
The lack of clear direction or communication thereof.

* C++ compatibility
* Everything GC-related
Probably a distant third is improving build tooling. But those
two are more important that everything else by an order of
magnitude.

Well yeah, but that's just the current clear direction. Who
knows what it will be next week.

[Andrei Alexandrescu via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d

Post by Sean Kelly via Digitalmars-d
The lack of clear direction or communication thereof.

* C++ compatibility
* Everything GC-related
Probably a distant third is improving build tooling. But those two are
more important that everything else by an order of magnitude.

Well yeah, but that's just the current clear direction. Who knows what
it will be next week.

It's been this for a good while, and it will probably be until done. --
Andrei

[Paolo Invernizzi via Digitalmars-d]

On Tuesday, 23 September 2014 at 16:19:31 UTC, Andrei

Post by Andrei Alexandrescu via Digitalmars-d

Post by Sean Kelly via Digitalmars-d
On Tuesday, 23 September 2014 at 15:47:21 UTC, Andrei

Post by Andrei Alexandrescu via Digitalmars-d

Post by Sean Kelly via Digitalmars-d
The lack of clear direction or communication thereof.

* C++ compatibility
Probably a distant third is improving build tooling. But
those two are
more important that everything else by an order of magnitude.

Well yeah, but that's just the current clear direction. Who
knows what
it will be next week.

It's been this for a good while, and it will probably be until
done. -- Andrei

Here at work I'm toying with C++ compatibility right now: If it's
viable, I would like to use D instead of C++ for a cloud tool
that must link with C++ computer vision libraries...

Right now it sounds promising, so this feature could really be
very interesting, not only to facilitate the integration with
existing in-house codebase, but also for brand new projects.

I'm starting to think that there will be a lot of buzz and fuss
about D as soon as good bindings to popular C++ libs will appear
in the wild...

---
/Paolo

[Andrei Alexandrescu via Digitalmars-d]

I'm starting to think that there will be a lot of buzz and fuss about D
as soon as good bindings to popular C++ libs will appear in the wild...

Yah, and core.stdcpp will be quite the surprise. -- Andrei

[Atila Neves via Digitalmars-d]

On Tuesday, 23 September 2014 at 16:50:26 UTC, Andrei

Post by Andrei Alexandrescu via Digitalmars-d

Post by Paolo Invernizzi via Digitalmars-d
I'm starting to think that there will be a lot of buzz and
fuss about D
as soon as good bindings to popular C++ libs will appear in
the wild...

Yah, and core.stdcpp will be quite the surprise. -- Andrei

Really?? Wow. Awesome!

Atila

[Jacob Carlborg via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d
It's been this for a good while, and it will probably be until done. --
Andrei

So why isn't there a publicly available road map? Note, this one [1]
doesn't mention C++ nor the GC.

[1] http://wiki.dlang.org/Agenda

[Andrei Alexandrescu via Digitalmars-d]

Post by Jacob Carlborg via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
It's been this for a good while, and it will probably be until done. --
Andrei

So why isn't there a publicly available road map? Note, this one [1]
doesn't mention C++ nor the GC.
[1] http://wiki.dlang.org/Agenda

Could you please update it? C++ and GC. C++ and GC. Thanks. -- Andrei

[kiran kumari via Digitalmars-d]

On Wednesday, 24 September 2014 at 06:13:11 UTC, Jacob Carlborg

Post by Jacob Carlborg via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
It's been this for a good while, and it will probably be until done. --
Andrei

So why isn't there a publicly available road map? Note, this
one [1] doesn't mention C++ nor the GC.
[1] http://wiki.dlang.org/Agenda

see more example
http://techgurulab.com/course/java-quiz-online/

[bearophile via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d
* C++ compatibility
* Everything GC-related
Probably a distant third is improving build tooling. But those
two are more important that everything else by an order of
magnitude.

In parallel there are other things like ddmd, checked ints in
core library, perhaps to finish shared libs, to test the patch
from Kenji that fixes the module system, and more.

Bye,
bearophile

[David Nadlinger via Digitalmars-d]

[
] and a lack of attention paid to tightening up what we've
already got and deprecating old stuff that no one wants any
more.

This. The hypocritical fear of making breaking changes (the fact
that not all of them are bad has been brought up over and over
again by some of the corporate users) is crippling us, making D a
much more cluttered language than necessary.

Seriously, once somebody comes up with an automatic fixup tool,
there is hardly any generic argument left against language
changes. Sure, there will always be some cases where manual
intervention is still required, such as with string mixins. But
unless we have lost hope that the D community is still to grow
significantly, I don't see why the burden of proof should
automatically lie on the side of those in favor of cleaning up
cruft and semantical quirks.

Most D code is still to be written.

David

[ketmar via Digitalmars-d]

On Tue, 23 Sep 2014 18:32:39 +0000

Post by David Nadlinger via Digitalmars-d
Seriously, once somebody comes up with an automatic fixup tool,

i bet nobody will. for many various reasons.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140923/6fef79e4/attachment.sig>

[Andrei Alexandrescu via Digitalmars-d]

[
] and a lack of attention paid to tightening up what we've already
got and deprecating old stuff that no one wants any more.

This. The hypocritical fear of making breaking changes (the fact that
not all of them are bad has been brought up over and over again by some
of the corporate users) is crippling us, making D a much more cluttered
language than necessary.
Seriously, once somebody comes up with an automatic fixup tool, there is
hardly any generic argument left against language changes. Sure, there
will always be some cases where manual intervention is still required,
such as with string mixins. But unless we have lost hope that the D
community is still to grow significantly, I don't see why the burden of
proof should automatically lie on the side of those in favor of cleaning
up cruft and semantical quirks.
Most D code is still to be written.

Well put. Again, the two things we need to work on are C++ compatibility
and the GC. -- Andrei

[Sean Kelly via Digitalmars-d]

On Tuesday, 23 September 2014 at 18:38:08 UTC, Andrei

Post by Andrei Alexandrescu via Digitalmars-d
Well put. Again, the two things we need to work on are C++
compatibility and the GC. -- Andrei

Has much thought gone into how we'll address C++ const?

[H. S. Teoh via Digitalmars-d]

Post by Sean Kelly via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
Well put. Again, the two things we need to work on are C++
compatibility and the GC. -- Andrei

Has much thought gone into how we'll address C++ const?

Is that even addressable?? D const is fundamentally different from C++
const. Short of introducing logical const into D, I don't see how we
could bridge the gap.


T

[Andrei Alexandrescu via Digitalmars-d]

Post by Sean Kelly via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
Well put. Again, the two things we need to work on are C++
compatibility and the GC. -- Andrei

Has much thought gone into how we'll address C++ const?

Some. A lot more needs to. -- Andrei

[Sean Kelly via Digitalmars-d]

On Tuesday, 23 September 2014 at 19:10:07 UTC, H. S. Teoh via

On Tue, Sep 23, 2014 at 07:01:05PM +0000, Sean Kelly via

Post by Sean Kelly via Digitalmars-d
On Tuesday, 23 September 2014 at 18:38:08 UTC, Andrei

Post by Andrei Alexandrescu via Digitalmars-d
Well put. Again, the two things we need to work on are C++
compatibility and the GC. -- Andrei

Has much thought gone into how we'll address C++ const?

Is that even addressable?? D const is fundamentally different
from C++
const. Short of introducing logical const into D, I don't see
how we
could bridge the gap.

I haven't really thought about it, but something could probably
be made to work with type wrappers that do implicit casting plus
just pretending that const is the same like we do with our C
interfaces. I'm also wondering how we'd handle something like:

struct S { virtual int foo() {...} };
std::map<int,S> m;

We'd have to make S a value type in D, so struct, but D struct
does't allow virtual functions. Maybe something weird with
in-place construction of classes? I suspect the more we look
into C++ compatibility the more problems we'll find, and actually
interfacing with most C++ code worth using will result in
terrifying D code. But I hope I'm wrong since C++ support is
apparently now where all of our effort is being devoted (mark me
down as being completely uninterested in this feature despite
using C/C++ at work).

[H. S. Teoh via Digitalmars-d]

On Tuesday, 23 September 2014 at 19:10:07 UTC, H. S. Teoh via Digitalmars-d

On Tue, Sep 23, 2014 at 07:01:05PM +0000, Sean Kelly via Digitalmars-d

[...]

Post by Sean Kelly via Digitalmars-d
Has much thought gone into how we'll address C++ const?

Is that even addressable?? D const is fundamentally different from
C++ const. Short of introducing logical const into D, I don't see how
we could bridge the gap.

I haven't really thought about it, but something could probably be
made to work with type wrappers that do implicit casting plus just
pretending that const is the same like we do with our C interfaces.
struct S { virtual int foo() {...} };
std::map<int,S> m;
We'd have to make S a value type in D, so struct, but D struct does't
allow virtual functions. Maybe something weird with in-place
construction of classes?

Or turn them into function pointers / member delegates? But that doesn't
work well with ABI compatibility.

I suspect the more we look into C++ compatibility the more problems
we'll find,

SFINAE is another dark corner of disaster waiting to happen, once we
decide to implement C++ template compatibility. As well as Koenig
lookup, which will become indispensible if D code is to actually use
non-trivial C++ libraries.

and actually interfacing with most C++ code worth using will result in
terrifying D code. But I hope I'm wrong since C++ support is
apparently now where all of our effort is being devoted (mark me down
as being completely uninterested in this feature despite using C/C++
at work).

Yeah, I can't say I'm exactly thrilled about being able to call C++ code
from D. I suppose it's a nice-to-have, but I'm not sure how well that's
gonna work in practice, given the fundamental differences between D and
C++.

But be that as it may, if we're serious about cross-linguistic ABI
compatibility, then we better start with a solid design of how exactly
said interfacing is going to happen in a way that fits in well with how
D works. Cowboying our way through piecemeal (i.e., ad hoc addition of
compatibilities like adding C++ class support, then C++ templates, then
SFINAE in extern(c++), then ...) isn't going to cut it. We might end up
reinventing C++, even more poorly than C++ already is.


T

[deadalnix via Digitalmars-d]

On Tuesday, 23 September 2014 at 20:22:32 UTC, H. S. Teoh via

Post by H. S. Teoh via Digitalmars-d
SFINAE is another dark corner of disaster waiting to happen,
once we
decide to implement C++ template compatibility. As well as
Koenig
lookup, which will become indispensible if D code is to
actually use
non-trivial C++ libraries.

We don't need these to be compatible with C++. We don't want to
be able to cut/paste C++ into a . file and expect it to compile,
but that you can map a reasonable amount of C++ constructs and
expect them to interact with the C++ code and back.

[Andrei Alexandrescu via Digitalmars-d]

Post by deadalnix via Digitalmars-d
On Tuesday, 23 September 2014 at 20:22:32 UTC, H. S. Teoh via

Post by H. S. Teoh via Digitalmars-d
SFINAE is another dark corner of disaster waiting to happen, once we
decide to implement C++ template compatibility. As well as Koenig
lookup, which will become indispensible if D code is to actually use
non-trivial C++ libraries.

We don't need these to be compatible with C++. We don't want to
be able to cut/paste C++ into a . file and expect it to compile,
but that you can map a reasonable amount of C++ constructs and
expect them to interact with the C++ code and back.

Yah, that's exactly it. Syntax and semantics stay D; the functions
called may be C++. -- Andrei

[H. S. Teoh via Digitalmars-d]

Post by deadalnix via Digitalmars-d
On Tuesday, 23 September 2014 at 20:22:32 UTC, H. S. Teoh via

Post by H. S. Teoh via Digitalmars-d
SFINAE is another dark corner of disaster waiting to happen, once we
decide to implement C++ template compatibility. As well as Koenig
lookup, which will become indispensible if D code is to actually use
non-trivial C++ libraries.

We don't need these to be compatible with C++. We don't want to
be able to cut/paste C++ into a . file and expect it to compile,
but that you can map a reasonable amount of C++ constructs and
expect them to interact with the C++ code and back.

You *will* need SFINAE if you expect to interface C++ template libraries
with D. Imagine that an existing codebase is using some C++ template
library that depends on SFINAE. You'd like to start migrating to D, so
you start writing new code in D. Eventually you need to make use of the
C++ template library in order to interface with the C++ parts of the
code, so you write a .di that declares template functions in an
extern(c++) block. It works... some of the time. Other times you start
getting weird errors or the wrong functions get called, because the C++
template library was written with SFINAE in mind, but D doesn't have
that. So at the end of the day, it's a gigantic mess, and you go
crawling back to C++.

Unless, of course, we draw the line at templates and say that we won't
support template compatibility with C++ (and I'd fully support that
decision!). But that means we throw all C++ template libraries out the
window, and any C++ codebase that makes heavy use of a template library
will have to be rewritten from scratch in D.

As for Koenig lookup, you might run into problems if you declare C++
wrappers for D functions in the C++ part of the codebase, and suddenly
the wrong D functions are getting called due to Koenig lookup in C++
which wasn't considered when the D part of the code was written.


T

[Andrei Alexandrescu via Digitalmars-d]

Post by H. S. Teoh via Digitalmars-d
You *will* need SFINAE if you expect to interface C++ template libraries
with D.

Nope. -- Andrei

[deadalnix via Digitalmars-d]

On Wednesday, 24 September 2014 at 00:08:19 UTC, H. S. Teoh via

Post by H. S. Teoh via Digitalmars-d
You *will* need SFINAE if you expect to interface C++ template
libraries
with D. Imagine that an existing codebase is using some C++
template
library that depends on SFINAE. You'd like to start migrating
to D, so
you start writing new code in D. Eventually you need to make
use of the
C++ template library in order to interface with the C++ parts
of the
code, so you write a .di that declares template functions in an
extern(c++) block. It works... some of the time. Other times
you start
getting weird errors or the wrong functions get called, because
the C++
template library was written with SFINAE in mind, but D doesn't
have
that. So at the end of the day, it's a gigantic mess, and you go
crawling back to C++.

I think you can support a large part of C++ template without
SFINAE. It is not that common and only matter for the binding if
it changes the interface or the layout of something.

If one want to map these, it can be done with some static if
magic. But I'm fairly confident that it won't even be necessary
is most situations.

[Jacob Carlborg via Digitalmars-d]

Seriously, once somebody comes up with an automatic fixup tool, there is
hardly any generic argument left against language changes.

Brain has already said that such a tool is fairly easy to create in many
cases. Also that he is willing do to so if it will be used. But so far
neither Andrei or Walter have shown any signs of willing to break code
that can be fixed with a tool like this. I can understand that Brian
doesn't want to create such a tool if it's not going to be used.

[Andrei Alexandrescu via Digitalmars-d]

Post by Jacob Carlborg via Digitalmars-d

Seriously, once somebody comes up with an automatic fixup tool, there is
hardly any generic argument left against language changes.

Brain has already said that such a tool is fairly easy to create in many
cases. Also that he is willing do to so if it will be used. But so far
neither Andrei or Walter have shown any signs of willing to break code
that can be fixed with a tool like this. I can understand that Brian
doesn't want to create such a tool if it's not going to be used.

Some breakage will going to happen even though we're increasingly
conservative. So yes, having a tool is nice.

Andrei

[ketmar via Digitalmars-d]

On Tue, 23 Sep 2014 14:29:05 +0000

Post by Sean Kelly via Digitalmars-d
function attributes. I'm sure someone likes them, but I'm
hell.

and 'const' is such overpowered that it's barely usable on methods and
struct/class fields.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140923/38c2136c/attachment.sig>

[Walter Bright via Digitalmars-d]

The lack of clear direction or communication thereof. A continual adding of new
stuff to try and appease the theoretical masses who will certainly come flocking
to D if implemented, and a lack of attention paid to tightening up what we've
already got and deprecating old stuff that no one wants any more.

I find this hard to reconcile with what the changelog says.

And inconsistency in how things work in the language. Oh, and function attributes.
I'm sure someone likes them, but I'm drowning in pure system const immutable
@nogc @illegitemate @wtf hell.

Fortunately, those attributes are inferred for template functions.

I did try to extend that to auto functions, but got a lot of resistance.

[Sean Kelly via Digitalmars-d]

On Wednesday, 24 September 2014 at 03:44:52 UTC, Walter Bright

Post by Walter Bright via Digitalmars-d

Post by Sean Kelly via Digitalmars-d
The lack of clear direction or communication thereof. A
continual adding of new
stuff to try and appease the theoretical masses who will
certainly come flocking
to D if implemented, and a lack of attention paid to
tightening up what we've
already got and deprecating old stuff that no one wants any
more.

I find this hard to reconcile with what the changelog says.

There's clearly been a lot of attention paid to bug fixes. But
for the rest... I feel like the overall direction is towards
whatever is currently thought to gain the most new users. The
thing is that D has already *got* me. What I want is for the
language I've already got to be polished until I can use it in a
freaking space telescope. I'm sick of "yes but" languages.
Every time I hit an obstacle in D I think "oh great, D is way
behind other languages in all these ways and D itself is broken
to boot. Why am I using this again?" And it could be a tiny
thing. It doesn't matter. Every little issue like that is
magnified a thousandfold because D is already such a hard sell.

So in that respect I understand the push for C++ support because
that's the speed bump that Andrei has hit. But here's the
thing... by pursuing this we're effectively focusing all of our
efforts *on another language*. And we're doing so when D itself
still needs a lot of work. Maybe not in any truly immense ways,
but as I said before, those tiny things can seem huge when you're
already struggling to justify just using the language at all.
Maybe all this will pull together into a cohesive whole, but so
far it feels kind of disconnected. So that's part of what I
meant by "tightening up."

Post by Walter Bright via Digitalmars-d

Post by Sean Kelly via Digitalmars-d
And inconsistency in how things work in the language. Oh, and function attributes.
I'm sure someone likes them, but I'm drowning in pure system
const immutable
@nogc @illegitemate @wtf hell.

Fortunately, those attributes are inferred for template
functions.
I did try to extend that to auto functions, but got a lot of
resistance.

Yes, the inference is very nice. And I do see the use for each
attribute. It's just... when I look at a function and there's a
line of attributes before the function declaration that have
nothing to do with what the function actually does but rather
with how it's implemented, it's just syntactic noise. It's
information for the compiler, not me as a user. I hope we'll
eventually get to the point where everything is inferred and the
attributes disappear entirely.

[Brad Roberts via Digitalmars-d]

There's clearly been a lot of attention paid to bug fixes. But for the
rest... I feel like the overall direction is towards whatever is
currently thought to gain the most new users. The thing is that D has
already *got* me. What I want is for the language I've already got to
be polished until I can use it in a freaking space telescope. I'm sick
of "yes but" languages. Every time I hit an obstacle in D I think "oh
great, D is way behind other languages in all these ways and D itself is
broken to boot. Why am I using this again?" And it could be a tiny
thing. It doesn't matter. Every little issue like that is magnified a
thousandfold because D is already such a hard sell.

I agree with Sean quite a bit here.

Let's turn the camera around and look at it from a different angle. I'm
hard pressed to find a new feature from the last few years that's
actually thoroughly complete. And by complete I mean that druntime and
phobos use it everywhere it should be used.

Shared libraries? nope.
Any of the new attributes? nope.
64 bit support? nope.
const?
shared?
cleaning up object?

.. nope.

And that's not even getting into the big gaps that exist.

I understand quite thoroughly why c++ support is a big win, or will be,
but the Oh Shiny focus is pretty discouraging for me as well. This
isn't meant to say the c++ work shouldn't be done, but to point out that
the shifting focus is a real problem.

[ketmar via Digitalmars-d]

On Tue, 23 Sep 2014 21:59:53 -0700

Post by Brad Roberts via Digitalmars-d
I understand quite thoroughly why c++ support is a big win

i believe it's not.

so-called "enterprise" will not choose D for many reasons, and "c++
interop" is on the bottom of the list.

seasoned c++ developer will not migrate to D for many reasons (or he
already did that, but then he is not c++ developer anymore), and "c++
interop" is not on the top of the list, not even near the top.

all that gory efforts aimed to "c++ interop" will bring three and a
half more users. there will be NO massive migration due to "better c++
interop". yet this feature is on the top of the list now. i'm sad.

seems that i (we?) have no choice except to wait until people will get
enough of c++ games and will became focused on D again. porting and
merging CDGC is much better target which help people already using D,
but... but imaginary "future adopters" seems to be the highest
priority. too bad that they will never arrive.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140924/6a7508e1/attachment.sig>

[Cliff via Digitalmars-d]

On Wednesday, 24 September 2014 at 05:44:15 UTC, ketmar via

Post by ketmar via Digitalmars-d
On Tue, 23 Sep 2014 21:59:53 -0700
Brad Roberts via Digitalmars-d <digitalmars-d at puremagic.com>

Post by Brad Roberts via Digitalmars-d
I understand quite thoroughly why c++ support is a big win

i believe it's not.
so-called "enterprise" will not choose D for many reasons, and
"c++
interop" is on the bottom of the list.
seasoned c++ developer will not migrate to D for many reasons
(or he
already did that, but then he is not c++ developer anymore),
and "c++
interop" is not on the top of the list, not even near the top.
all that gory efforts aimed to "c++ interop" will bring three
and a
half more users. there will be NO massive migration due to
"better c++
interop". yet this feature is on the top of the list now. i'm
sad.
seems that i (we?) have no choice except to wait until people
will get
enough of c++ games and will became focused on D again. porting
and
merging CDGC is much better target which help people already
using D,
but... but imaginary "future adopters" seems to be the highest
priority. too bad that they will never arrive.

Why does anyone have to *wait* for anything? I'm not seeing the
blocking issues regarding attempts to fix the language. People
are making PRs, people are discussing and testing ideas, and
there appear to be enough people to tackle several problems at
once (typedefs, C++ interop, GC/RC issues, weirdness with ref and
auto, import symbol shadowing, etc.) Maybe things aren't moving
as swiftly as we would like in the areas which are most impactful
*to us* but that is the nature of free software. Has it ever
been any other way than that the things which get the most
attention are the things which the individual contributors are
the most passionate about (whether their passion is justified or
not?)

[H. S. Teoh via Digitalmars-d]

[...]

There's clearly been a lot of attention paid to bug fixes. But for
the rest... I feel like the overall direction is towards whatever is
currently thought to gain the most new users. The thing is that D has
already *got* me. What I want is for the language I've already got to
be polished until I can use it in a freaking space telescope. I'm
sick of "yes but" languages. Every time I hit an obstacle in D I
think "oh great, D is way behind other languages in all these ways and
D itself is broken to boot. Why am I using this again?" And it could
be a tiny thing. It doesn't matter. Every little issue like that is
magnified a thousandfold because D is already such a hard sell.

Yeah, I wish that at least *some* attention would be paid to refining
existing features so that problematic corner cases could be ironed out.
Like identifier lookup rules for local imports. And what to do about
dtors. And so many little niggling details that seem minor, but added
together, can form a pretty big mountain of frustration sometimes.


[...]

Post by Walter Bright via Digitalmars-d

And inconsistency in how things work in the language. Oh, and
function attributes. I'm sure someone likes them, but I'm drowning

Fortunately, those attributes are inferred for template functions.
I did try to extend that to auto functions, but got a lot of
resistance.

I support attribute inference for auto functions. The more inference,
the better, I say. That's the only way attributes will become
practically useful.

Yes, the inference is very nice. And I do see the use for each
attribute. It's just... when I look at a function and there's a line
of attributes before the function declaration that have nothing to do
with what the function actually does but rather with how it's
implemented, it's just syntactic noise. It's information for the
compiler, not me as a user. I hope we'll eventually get to the point
where everything is inferred and the attributes disappear entirely.

I haven't actually tried this yet, but I'm been toying with the idea of
writing *all* functions as template functions (except where impossible,
like virtual functions), even if they would take only zero compile-time
arguments. This way, I reap the benefits of attribute inference, *and* I
also get automatic culling of unused functions from the executable ('cos
they wouldn't be instantiated in the first place).


T

[Walter Bright via Digitalmars-d]

Post by H. S. Teoh via Digitalmars-d
Yeah, I wish that at least *some* attention would be paid to refining
existing features so that problematic corner cases could be ironed out.

It's kinda maddening to hear statements like that. Just in 2.066:

103 compiler regressions fixed
235 compiler bugs fixed
39 language enhancements
12 phobos regressions fixed
110 phobos bugs fixed
41 phobos enhancements
9 druntime regressions fixed
17 druntime bugs fixed
9 druntime enhancements

https://dlang.org/changelog.html#list2066

Post by H. S. Teoh via Digitalmars-d
Like identifier lookup rules for local imports.

Suddenly this issue goes to a mountain overnight. Is it really the most
critical, important problem, overshadowing everything else?

Post by H. S. Teoh via Digitalmars-d
And what to do about
dtors. And so many little niggling details that seem minor, but added
together, can form a pretty big mountain of frustration sometimes.

So help out!

Post by H. S. Teoh via Digitalmars-d
I haven't actually tried this yet, but I'm been toying with the idea of
writing *all* functions as template functions (except where impossible,
like virtual functions), even if they would take only zero compile-time
arguments. This way, I reap the benefits of attribute inference, *and* I
also get automatic culling of unused functions from the executable ('cos
they wouldn't be instantiated in the first place).

Yup, give it a try.

[Walter Bright via Digitalmars-d]

Post by Walter Bright via Digitalmars-d

Post by H. S. Teoh via Digitalmars-d
Yeah, I wish that at least *some* attention would be paid to refining
existing features so that problematic corner cases could be ironed out.

So help out!

I note that you've had many contributions accepted, this is great:

https://github.com/D-Programming-Language/dmd/pulls?q=is%3Apr+is%3Aclosed+author%3Aquickfur

https://github.com/D-Programming-Language/phobos/pulls?q=is%3Apr+author%3Aquickfur

So please work on the refinements you wish for!

[Jacob Carlborg via Digitalmars-d]

Post by Walter Bright via Digitalmars-d
So help out!

You always say we should help out instead of complaining. But where are
all the users that want C++ support. Let them implement it instead and
lets us focus on actual D users we have now.

[Andrei Alexandrescu via Digitalmars-d]

Post by Jacob Carlborg via Digitalmars-d

Post by Walter Bright via Digitalmars-d
So help out!

You always say we should help out instead of complaining. But where are
all the users that want C++ support. Let them implement it instead and
lets us focus on actual D users we have now.

This thinking is provincial and damaging. We need to focus on both
retaining our current users as well as in getting to the next level of
magnitude. And for that we need C++ compatibility and improving
everything about the GC story. -- Andrei

[Andrei Alexandrescu via Digitalmars-d]

So in that respect I understand the push for C++ support because that's
the speed bump that Andrei has hit. But here's the thing... by pursuing
this we're effectively focusing all of our efforts *on another
language*. And we're doing so when D itself still needs a lot of work.
Maybe not in any truly immense ways, but as I said before, those tiny
things can seem huge when you're already struggling to justify just
using the language at all. Maybe all this will pull together into a
cohesive whole, but so far it feels kind of disconnected. So that's
part of what I meant by "tightening up."

You need a spoon of rennet to turn a bucket of milk into a bucket of
yogurt. No matter how much milk you add, that won't help. You want to
add milk. I know we must add rennet. -- Andrei

[Jacob Carlborg via Digitalmars-d]

Post by Brad Roberts via Digitalmars-d
I agree with Sean quite a bit here.
Let's turn the camera around and look at it from a different angle. I'm
hard pressed to find a new feature from the last few years that's
actually thoroughly complete. And by complete I mean that druntime and
phobos use it everywhere it should be used.
Shared libraries? nope.
Any of the new attributes? nope.
64 bit support? nope.
const?
shared?
cleaning up object?
.. nope.
And that's not even getting into the big gaps that exist.

I completely agree. Lets focus on the D users we actually have, not some
imaginary C++ users that will come running as soon as there is enough
C++ support.

[Andrei Alexandrescu via Digitalmars-d]

Post by Jacob Carlborg via Digitalmars-d

Post by Brad Roberts via Digitalmars-d
I agree with Sean quite a bit here.
Let's turn the camera around and look at it from a different angle. I'm
hard pressed to find a new feature from the last few years that's
actually thoroughly complete. And by complete I mean that druntime and
phobos use it everywhere it should be used.
Shared libraries? nope.
Any of the new attributes? nope.
64 bit support? nope.
const?
shared?
cleaning up object?
.. nope.
And that's not even getting into the big gaps that exist.

I completely agree. Lets focus on the D users we actually have, not some
imaginary C++ users that will come running as soon as there is enough
C++ support.

Those are very real. I know this for a fact. -- Andrei

[kiran kumari via Digitalmars-d]

On Wednesday, 24 September 2014 at 06:24:21 UTC, Andrei

Post by Andrei Alexandrescu via Digitalmars-d

Post by Jacob Carlborg via Digitalmars-d

Post by Brad Roberts via Digitalmars-d
I agree with Sean quite a bit here.
Let's turn the camera around and look at it from a different
angle. I'm
hard pressed to find a new feature from the last few years
that's
actually thoroughly complete. And by complete I mean that
druntime and
phobos use it everywhere it should be used.
Shared libraries? nope.
Any of the new attributes? nope.
64 bit support? nope.
const?
shared?
cleaning up object?
.. nope.
And that's not even getting into the big gaps that exist.

I completely agree. Lets focus on the D users we actually
have, not some
imaginary C++ users that will come running as soon as there is enough
C++ support.

Those are very real. I know this for a fact. -- Andrei

see more example
http://techgurulab.com/course/java-quiz-online/

[Thomas Mader via Digitalmars-d]

Post by Sean Kelly via Digitalmars-d
Yes, the inference is very nice. And I do see the use for each
attribute. It's just... when I look at a function and there's
a line of attributes before the function declaration that have
nothing to do with what the function actually does but rather
with how it's implemented, it's just syntactic noise. It's
information for the compiler, not me as a user. I hope we'll
eventually get to the point where everything is inferred and
the attributes disappear entirely.

What is the problem with complete automatic inference?
Wouldn't it be possible to deduce the flags in the bottom up
direction of a function call hierarchy?
I guess it is possible for the compiler to see the right choice
of flags for a function, which doesn't call other functions. E.g.
make it @safe if possible, @nogc if possible and so on.
Then it should process function after function until all
functions are done.

Thomas

[Rikki Cattermole via Digitalmars-d]

Post by Tofu Ninja via Digitalmars-d
GC by default is a big sore point that everyone brings up

I like having a GC by default. But we really need to think of it as a
last resort sort of thing.

Post by Tofu Ninja via Digitalmars-d
"is" expressions are pretty wonky

Ehh yeah, D3 we could I spose.

Post by Tofu Ninja via Digitalmars-d
Libraries could definitely be split up better

We can still fix that in D2.

Just as a note, we do want AST macros for D3. Which will be awesome!
Stuff like linq from c# could be done as a library.

[Ola Fosheim Grostad via Digitalmars-d]

On Saturday, 20 September 2014 at 13:31:06 UTC, Rikki Cattermole

Post by Rikki Cattermole via Digitalmars-d
Just as a note, we do want AST macros for D3. Which will be
awesome!

What kind of macros? Generic AST macros probably make source to
source translation just as difficult as string mixins, don't
they? Some simple term-rewriting is probably cleaner?

[Rikki Cattermole via Digitalmars-d]

Post by Rikki Cattermole via Digitalmars-d
Just as a note, we do want AST macros for D3. Which will be awesome!

What kind of macros? Generic AST macros probably make source to source
translation just as difficult as string mixins, don't they? Some simple
term-rewriting is probably cleaner?

Maybe idk.
I haven't investigated this sort of technology. I only know whats being
planned for.

[Tofu Ninja via Digitalmars-d]

Post by Tofu Ninja via Digitalmars-d
What do you think are the worst parts of D?

Oh another bad part of D is the attribute names with some being
positive(pure) and some being negative(@nogc) and some of them
not having an @ on them.

[Andrei Alexandrescu via Digitalmars-d]

Post by Tofu Ninja via Digitalmars-d

Post by Tofu Ninja via Digitalmars-d
What do you think are the worst parts of D?

Oh another bad part of D is the attribute names with some being

If that's among the worst, yay :o).

My pet peeves about D gravitate around the lack of a clear approach to
escape analysis and the sometimes confusing interaction of qualifiers
with constructors.

For escape analysis, I think the limited form present inside
constructors (that enforces forwarded this() calls to execute exactly
once) is plenty fine and should be applied in other places as well.

For qualifiers, I think we need an overhaul of the interaction of
qualifiers with copy construction.


Andrei

[monarch_dodra via Digitalmars-d]

On Saturday, 20 September 2014 at 16:54:08 UTC, Andrei

Post by Andrei Alexandrescu via Digitalmars-d

On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja

Post by Tofu Ninja via Digitalmars-d
What do you think are the worst parts of D?

Oh another bad part of D is the attribute names with some being

If that's among the worst, yay :o).
My pet peeves about D gravitate around the lack of a clear
approach to escape analysis and the sometimes confusing
interaction of qualifiers with constructors.
For escape analysis, I think the limited form present inside
constructors (that enforces forwarded this() calls to execute
exactly once) is plenty fine and should be applied in other
places as well.

I think correct escape analysis + @safe + scope == win.

BTW, remember all those people that bitch about rvalue to "const
ref". D could be a language that provides rvalue to scope ref.
100% safe and practical. How awesome would that be?

[kiran kumari via Digitalmars-d]

On Saturday, 20 September 2014 at 16:54:08 UTC, Andrei

Post by Andrei Alexandrescu via Digitalmars-d

On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja

Post by Tofu Ninja via Digitalmars-d
What do you think are the worst parts of D?

Oh another bad part of D is the attribute names with some being

If that's among the worst, yay :o).
My pet peeves about D gravitate around the lack of a clear
approach to escape analysis and the sometimes confusing
interaction of qualifiers with constructors.
For escape analysis, I think the limited form present inside
constructors (that enforces forwarded this() calls to execute
exactly once) is plenty fine and should be applied in other
places as well.
For qualifiers, I think we need an overhaul of the interaction
of qualifiers with copy construction.
see more example

http://techgurulab.com/course/java-quiz-online/

[ketmar via Digitalmars-d]

On Sat, 20 Sep 2014 14:42:47 +0000

Post by Tofu Ninja via Digitalmars-d
Oh another bad part of D is the attribute names with some being

and no way to revert 'final' in classes, for example. or 'static'. i
mean that i want something like this:

class A {
final:
void foo () { ... }
virtual:
void bar () { ... }
static:
void heh () { ... }
// and there is no way to declare non-static fields anymore...
}

yes, i know that i can use `final {}`, but it looking ugly. and i
prefer to declare fields at the end of class declaration. annoying.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140920/b67c29de/attachment.sig>

[K.K. via Digitalmars-d]

I watched Jonathan's talk last night, it was really good. I
really like the idea that he wants to make a community designed,
platform independent, game specific language. It's too bad he
doesn't really want to give D more of chance but for what he's
looking for, it'd really need to be designed from the ground up,
as he was saying. Also being that he's slowly rejecting C++, then
I can see D not making sense since D's slogan is pretty much "A
better C++!"; which is accurate but may not be the best marketing
scheme. Also D is a general purpose language, so I guess it
really wouldn't fit his bill.
Though he mentioned Go and Rust a lot, personally I wouldn't
really back those languages either, at least not for games. Rust
maybe if it ever hits version 1.0 I'll take another look at it.
I'm definitely all for the setup he was describing though: all
you need is an IDE/text editor and the compiler. I feel like D
definitely has the potential to be able to meet that setup
someday; I'm just not sure if that setup would be a screw over or
not to people of other fields. The platform independent thing
would be a HUGE plus! Something D isn't too, too far from, but
definitely not there at least of yet.

Overall I'd say D has some significant issues:

- The documentation is awful. If there's a problem you don't know
the answer to, the only three real options are pray that the docs
are correct/up to date, go ask someone who possibly does know, or
magic.

- Bugs. D is like Costco, expect for bugs, and all the bugs are
free.

- More of a suggestion than a problem: Someone needs to do an
O'reilly book series for D; but only after the first two problems
I listed are at least suppressed a bit.

- Very few native D libraries, and also for C/other libraries
almost all D bindings are maintained by usually only one person.
Usually very skilled people, but the work load for library
development and maintenance would probably thrive best with more
people doing more. (The community is probably just too small at
the moment)


....I'm sure there was more, but it's just not coming to me at
the moment.
I'm definitely interested in Jon's theoretical language but I
don't think it's gonna take away from D for me.

Overall though, I absolutely love D! There's just ALOT of work to
be done. :)

[Brian Schott via Digitalmars-d]

Post by Tofu Ninja via Digitalmars-d
What do you think are the worst parts of D?

This compiles.

https://github.com/Hackerpilot/Idiotmatic-D/blob/master/idiotmatic.d

[H. S. Teoh via Digitalmars-d]

Post by Brian Schott via Digitalmars-d

Post by Tofu Ninja via Digitalmars-d
What do you think are the worst parts of D?

This compiles.
https://github.com/Hackerpilot/Idiotmatic-D/blob/master/idiotmatic.d

+1, lolz.

Oh wait, you forgot is(...) syntax (and their various inconsistent
semantics)! Plz add. ;-)


T

[Adam D. Ruppe via Digitalmars-d]

On Saturday, 20 September 2014 at 23:01:40 UTC, H. S. Teoh via

Post by H. S. Teoh via Digitalmars-d
Oh wait, you forgot is(...) syntax (and their various
inconsistent semantics)! Plz add. ;-)

I used to hate is()... but then I spent the time to understand it
to write about it in my book and now it doesn't bother me
anymore. It is a bit weird looking, but there's a perfectly
understandable pattern and logic to it; it makes sense once you
get it.


The two alias syntaxes don't but me either, the old one was fine,
the new one is cool too. I'd be annoyed if the old one
disappeared cuz of compatibility tho.

That said, I want the C style array declaration to die die die,
that's just evil. But the old style alias is ok.

Post by H. S. Teoh via Digitalmars-d
string results[](T) = "I have no idea what I'm doing";

I agree that's just weird though, someone pointed that out to me
on IRC and I was even like wtf. I had thought I've seen it all
until then.

[Tofu Ninja via Digitalmars-d]

On Saturday, 20 September 2014 at 23:07:16 UTC, Adam D. Ruppe

Post by Adam D. Ruppe via Digitalmars-d

Post by H. S. Teoh via Digitalmars-d
string results[](T) = "I have no idea what I'm doing";

I agree that's just weird though, someone pointed that out to
me on IRC and I was even like wtf. I had thought I've seen it
all until then.

I literally don't even know what to expect this to do.

[Daniel Murphy via Digitalmars-d]

Post by Tofu Ninja via Digitalmars-d

Post by H. S. Teoh via Digitalmars-d
string results[](T) = "I have no idea what I'm doing";

I agree that's just weird though, someone pointed that out to me on IRC
and I was even like wtf. I had thought I've seen it all until then.

I literally don't even know what to expect this to do.

template results(T)
{
string[] results = "I have no idea what I'm doing";
}

Which won't instantiate because string doesn't convert to string[].

A fun mix of C-style array syntax, shortened template declaration syntax and
a semantic error.

[Timon Gehr via Digitalmars-d]

Post by Daniel Murphy via Digitalmars-d

Post by H. S. Teoh via Digitalmars-d
string results[](T) = "I have no idea what I'm doing";

I agree that's just weird though, someone pointed that out to me on

IRC > and I was even like wtf. I had thought I've seen it all until then.
I literally don't even know what to expect this to do.

template results(T)
{
string[] results = "I have no idea what I'm doing";
}
Which won't instantiate because string doesn't convert to string[].
A fun mix of C-style array syntax, shortened template declaration syntax
and a semantic error.

When was int x(T)=2; introduced? Also, C-style array syntax would
actually be string results(T)[] = "";.

[Daniel Murphy via Digitalmars-d]

Post by Timon Gehr via Digitalmars-d
When was int x(T)=2; introduced?

At the same time as enum x(T) = 2; I think.

Post by Timon Gehr via Digitalmars-d
Also, C-style array syntax would actually be string results(T)[] = "";.

Nah, array type suffix goes before the template argument list.

[Timon Gehr via Digitalmars-d]

Post by Daniel Murphy via Digitalmars-d

Post by Timon Gehr via Digitalmars-d
When was int x(T)=2; introduced?

At the same time as enum x(T) = 2; I think.
...

Is this documented?

Post by Daniel Murphy via Digitalmars-d

Post by Timon Gehr via Digitalmars-d
Also, C-style array syntax would actually be string results(T)[] = "";.

Nah, array type suffix goes before the template argument list.

It is results!T[2], not results[2]!T.

[Brian Schott via Digitalmars-d]

On Saturday, 20 September 2014 at 23:07:16 UTC, Adam D. Ruppe

Post by Adam D. Ruppe via Digitalmars-d
I agree that's just weird though, someone pointed that out to
me on IRC and I was even like wtf. I had thought I've seen it
all until then.

The people who write books and autocompletion engines look at
things the compiler accepts and say "WTF!?".

I think that's the worst thing you can say about D.

[Tofu Ninja via Digitalmars-d]

On Saturday, 20 September 2014 at 22:53:05 UTC, Brian Schott

On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja

Post by Tofu Ninja via Digitalmars-d
What do you think are the worst parts of D?

This compiles.
https://github.com/Hackerpilot/Idiotmatic-D/blob/master/idiotmatic.d

I laughed extremely hard at this, wow. Yeah that definitely
highlight A LOT of problems.

[Walter Bright via Digitalmars-d]

Post by Brian Schott via Digitalmars-d

Post by Tofu Ninja via Digitalmars-d
What do you think are the worst parts of D?

This compiles.
https://github.com/Hackerpilot/Idiotmatic-D/blob/master/idiotmatic.d

https://github.com/D-Programming-Language/dmd/pull/4021

produces:

test.d(7): Warning: instead of C-style 'T id[]' syntax, use D-style 'T[]' id syntax
test.d(8): Warning: instead of C-style 'T id[]' syntax, use D-style 'T[]' id syntax
test.d(11): Warning: instead of C-style 'T id[exp]' syntax, use D-style 'T[exp]
id' syntax
test.d(15): Warning: instead of C-style 'T id[type]' syntax, use D-style
'T[type]' id syntax
test.d(57): Warning: instead of C-style 'T id[]' syntax, use D-style 'T[]' id syntax
test.d(94): Warning: instead of C-style 'T id[]' syntax, use D-style 'T[]' id syntax
test.d(103): Warning: instead of C-style 'T id[]' syntax, use D-style 'T[]' id
syntax

I.e. resolves 7 of them. :-)

[Vladimir Panteleev via Digitalmars-d]

Post by Tofu Ninja via Digitalmars-d
What do you think are the worst parts of D?

The regressions!

https://issues.dlang.org/buglist.cgi?bug_severity=regression&list_id=106988&resolution=---

I filed over half of those...

[via Digitalmars-d]

On Sunday, 21 September 2014 at 00:07:36 UTC, Vladimir Panteleev

On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja

Post by Tofu Ninja via Digitalmars-d
What do you think are the worst parts of D?

The regressions!
https://issues.dlang.org/buglist.cgi?bug_severity=regression&list_id=106988&resolution=---
I filed over half of those...

I guess you found them using your own code base? Maybe it would
make sense to add one or more larger projects to the autotester,
in addition to the unit tests. They don't necessarily need to be
blocking, just a notice "hey, your PR broke this and that
project" would surely be helpful to detect the breakages early on.

[H. S. Teoh via Digitalmars-d]

Post by Vladimir Panteleev via Digitalmars-d

Post by Tofu Ninja via Digitalmars-d
What do you think are the worst parts of D?

The regressions!
https://issues.dlang.org/buglist.cgi?bug_severity=regression&list_id=106988&resolution=---
I filed over half of those...

I guess you found them using your own code base? Maybe it would make
sense to add one or more larger projects to the autotester, in
addition to the unit tests. They don't necessarily need to be
blocking, just a notice "hey, your PR broke this and that project"
would surely be helpful to detect the breakages early on.

This has been suggested before. The problem is resources. If you're
willing to donate equipment for running these tests, it would be greatly
appreciated, I believe.

For my part, I regularly try compiling my own projects with git HEAD,
and filing any regressions I find.


T

[luminousone via Digitalmars-d]

On Sunday, 21 September 2014 at 22:17:59 UTC, H. S. Teoh via

On Sun, Sep 21, 2014 at 08:49:38AM +0000, via Digitalmars-d

Post by via Digitalmars-d
On Sunday, 21 September 2014 at 00:07:36 UTC, Vladimir

On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja

Post by Tofu Ninja via Digitalmars-d
What do you think are the worst parts of D?

The regressions!
https://issues.dlang.org/buglist.cgi?bug_severity=regression&list_id=106988&resolution=---
I filed over half of those...

I guess you found them using your own code base? Maybe it
would make
sense to add one or more larger projects to the autotester, in
addition to the unit tests. They don't necessarily need to be
blocking, just a notice "hey, your PR broke this and that
project"
would surely be helpful to detect the breakages early on.

This has been suggested before. The problem is resources. If
you're
willing to donate equipment for running these tests, it would
be greatly
appreciated, I believe.
For my part, I regularly try compiling my own projects with git
HEAD,
and filing any regressions I find.
T

What is needed?

[Walter Bright via Digitalmars-d]

Post by luminousone via Digitalmars-d
What is needed?

The people who maintain large projects need to try them out with the beta
compilers and file any regressions.

[Vladimir Panteleev via Digitalmars-d]

On Wednesday, 24 September 2014 at 04:00:06 UTC, Walter Bright

Post by Walter Bright via Digitalmars-d

Post by luminousone via Digitalmars-d
What is needed?

The people who maintain large projects need to try them out
with the beta compilers and file any regressions.

Question: What's the point of testing betas if the release will
occur even with known regressions? Blocking a pull being merged
would be much more efficient than dealing with a pull merged long
ago that by release time is difficult to revert.

[Walter Bright via Digitalmars-d]

Post by Walter Bright via Digitalmars-d

Post by luminousone via Digitalmars-d
What is needed?

The people who maintain large projects need to try them out with the beta
compilers and file any regressions.

Question: What's the point of testing betas if the release will occur even with
known regressions?

Framing the question that way implies that all regressions are equally
deleterious. But this isn't true at all - some regressions are disastrous, some
are just minor nits. Delaying the release has its costs, too, as it may fix a
number of serious problems.

It's a balancing act.

We shouldn't hamstring our ability to do what is best by conforming to arbitrary
rules whether they are right or wrong for the circumstances.

Blocking a pull being merged would be much more efficient
than dealing with a pull merged long ago that by release time is difficult to
revert.

Sure. I would block pulls that produce known regressions. The earlier
regressions are known the better. But it is a bit unreasonable to expect large
project maintainers to rebuild and check for bugs every day. It's why we have a
beta test program.

[Jacob Carlborg via Digitalmars-d]

Post by Walter Bright via Digitalmars-d
But it is a bit unreasonable to expect
large project maintainers to rebuild and check for bugs every day. It's
why we have a beta test program.

The solution is to make it automatic.

[kiran kumari via Digitalmars-d]

On Wednesday, 24 September 2014 at 06:24:39 UTC, Jacob Carlborg

Post by Jacob Carlborg via Digitalmars-d

Post by Walter Bright via Digitalmars-d
But it is a bit unreasonable to expect
large project maintainers to rebuild and check for bugs every
day. It's
why we have a beta test program.

The solution is to make it automatic.

see more example
http://techgurulab.com/course/java-quiz-online/

[Walter Bright via Digitalmars-d]

Post by H. S. Teoh via Digitalmars-d

Post by Vladimir Panteleev via Digitalmars-d

Post by Tofu Ninja via Digitalmars-d
What do you think are the worst parts of D?

The regressions!
https://issues.dlang.org/buglist.cgi?bug_severity=regression&list_id=106988&resolution=---
I filed over half of those...

I guess you found them using your own code base? Maybe it would make
sense to add one or more larger projects to the autotester, in
addition to the unit tests. They don't necessarily need to be
blocking, just a notice "hey, your PR broke this and that project"
would surely be helpful to detect the breakages early on.

This has been suggested before. The problem is resources. If you're
willing to donate equipment for running these tests, it would be greatly
appreciated, I believe.

No, that's not the problem. The problem is what to do when the "larger project"
fails.

Currently, it is the submitter's job to adjust the test suite, fix phobos code,
whatever is necessary to get the suite running again. Sometimes, in the more
convoluted Phobos code, this can be a real challenge.

Now replace that with somewhere in a large project, which our poor submitter
knows absolutely nothing about, it fails. You're asking him to go in, understand
this large project, determine if it's a problem with his submission or a problem
with the large project, and fix it.

At some level, then WE become the maintainers of that large project.

This is completely unworkable.

[Vladimir Panteleev via Digitalmars-d]

On Wednesday, 24 September 2014 at 03:59:10 UTC, Walter Bright

Post by Walter Bright via Digitalmars-d
This is completely unworkable.

Mister, please stop hurting the pool straw man.

Post by Walter Bright via Digitalmars-d

They don't necessarily need to be blocking, just a notice
"hey, your PR broke this and that project" would surely be
helpful to detect the breakages early on.

I think that aside from the technical limitations, that's
completely reasonable, and does not put any undue obligation on
anyone.

[Walter Bright via Digitalmars-d]

Post by Vladimir Panteleev via Digitalmars-d

Post by Walter Bright via Digitalmars-d
This is completely unworkable.

Mister, please stop hurting the pool straw man.

Post by Walter Bright via Digitalmars-d

They don't necessarily need to be blocking, just a notice "hey, your PR
broke this and that project" would surely be helpful to detect the breakages
early on.

I think that aside from the technical limitations, that's completely reasonable,
and does not put any undue obligation on anyone.

Who is going to maintain the autotester version of these projects?

What I'd like to see is the autotester regularly build release packages out of
HEAD. Then, large project maintainers can create their own scripts to download
the latest compiler and attempt to build their project.

[Jacob Carlborg via Digitalmars-d]

Post by Walter Bright via Digitalmars-d
No, that's not the problem. The problem is what to do when the "larger
project" fails.
Currently, it is the submitter's job to adjust the test suite, fix
phobos code, whatever is necessary to get the suite running again.
Sometimes, in the more convoluted Phobos code, this can be a real
challenge.
Now replace that with somewhere in a large project, which our poor
submitter knows absolutely nothing about, it fails. You're asking him to
go in, understand this large project, determine if it's a problem with
his submission or a problem with the large project, and fix it.

If it worked before and now it doesn't, then it sounds like a regression
to me.

Post by Walter Bright via Digitalmars-d
At some level, then WE become the maintainers of that large project.
This is completely unworkable.

The author of the library could at least get a notification.

[kiran kumari via Digitalmars-d]

On Wednesday, 24 September 2014 at 06:27:54 UTC, Jacob Carlborg

Post by Jacob Carlborg via Digitalmars-d

Post by Walter Bright via Digitalmars-d
No, that's not the problem. The problem is what to do when the "larger
project" fails.
Currently, it is the submitter's job to adjust the test suite, fix
phobos code, whatever is necessary to get the suite running
again.
Sometimes, in the more convoluted Phobos code, this can be a
real
challenge.
Now replace that with somewhere in a large project, which our
poor
submitter knows absolutely nothing about, it fails. You're
asking him to
go in, understand this large project, determine if it's a
problem with
his submission or a problem with the large project, and fix it.

If it worked before and now it doesn't, then it sounds like a
regression to me.

Post by Walter Bright via Digitalmars-d
At some level, then WE become the maintainers of that large
project.
This is completely unworkable.

The author of the library could at least get a notification.

see ore example
mhttp://techgurulab.com/course/java-quiz-online/ore example

[deadalnix via Digitalmars-d]

Post by Tofu Ninja via Digitalmars-d
There was a recent video[1] by Jonathan Blow about what he
would want in a programming language designed specifically for
game development. Go, Rust, and D were mentioned and his reason
for not wanting to use D is is that it is "too much like C++"
although he does not really go into it much and it was a very
small part of the video it still brings up some questions.
What I am curious is what are the worst parts of D? What sort
of things would be done differently if we could start over or
if we were designing a D3? I am not asking to try and bash D
but because it is helpful to know what's bad as well as good.
I will start off...
GC by default is a big sore point that everyone brings up
"is" expressions are pretty wonky
Libraries could definitely be split up better
What do you think are the worst parts of D?
[1] http://youtu.be/TH9VCN6UkyQ

1. Accidental complexity.
2. Introducing hacks to solve issues instead of going for a
clean solution, because it reduce complexity in the short run
(and create 1. on the long run).

[ponce via Digitalmars-d]

Post by Tofu Ninja via Digitalmars-d
What do you think are the worst parts of D?

Proper D code is supposed to have lots of attributes (pure const
nothrow @nogc) that brings little and makes it look bad.

[Andrei Alexandrescu via Digitalmars-d]

Post by Tofu Ninja via Digitalmars-d
What do you think are the worst parts of D?

Proper D code is supposed to have lots of attributes (pure const nothrow
@nogc) that brings little and makes it look bad.

No because deduction. -- Andrei

[Iain Buclaw via Digitalmars-d]

On 21 September 2014 15:54, Andrei Alexandrescu via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d

Post by Tofu Ninja via Digitalmars-d
What do you think are the worst parts of D?

Proper D code is supposed to have lots of attributes (pure const nothrow
@nogc) that brings little and makes it look bad.

No because deduction. -- Andrei

Agreed. The time when you want to explicitly use these attributes is
if you want to enforce @nogc, pure ...

As it turns out, it is a good idea to enforce these from the start,
rather than after you've written your program.

Iain

[H. S. Teoh via Digitalmars-d]

Post by ponce via Digitalmars-d

Post by Tofu Ninja via Digitalmars-d
What do you think are the worst parts of D?

Proper D code is supposed to have lots of attributes (pure const

To be fair, though, hindsight is always 20/20. Had we known earlier that
we would have these attributes, they would've been default to begin
with, and you'd have to explicitly ask for impure / mutable / throwing /
@withgc.

But on the positive side, the compiler will automatically infer
attributes for template functions, and lately I've been tempted to write
templated functions by default just to get the attribute inference
bonus, even if it's just translating fun(a,b,c) to fun()(a,b,c). The
caller site never has to change, and the function is never instantiated
more than once -- and you get the added bonus that if the function is
never actually called, then it doesn't even appear in the executable.

Attribute inference is the way to go, IMO. Research has shown that
people generally don't bother with writing properly-attributed
declarations -- it's too tedious and easily overlooked. Having "nicer"
attributes be the default helps somewhat, but attribute inference is
ultimately what might actually stand a chance of solving this problem.


T

[Ola Fosheim Grostad via Digitalmars-d]

On Sunday, 21 September 2014 at 22:41:04 UTC, H. S. Teoh via

Post by H. S. Teoh via Digitalmars-d
with, and you'd have to explicitly ask for impure / mutable

"Impure" should be on parameters so you can do dataflow in the
presence of FFI.

So you basically need better mechanisms.

But then you have to analyze the needs first (e.g. the desirable
semantics that currently are avoided) All of then.

Adding one hack after the other is not the best approach.

[H. S. Teoh via Digitalmars-d]

On Sunday, 21 September 2014 at 22:41:04 UTC, H. S. Teoh via Digitalmars-d

Post by H. S. Teoh via Digitalmars-d
with, and you'd have to explicitly ask for impure / mutable

"Impure" should be on parameters so you can do dataflow in the
presence of FFI.
So you basically need better mechanisms.
But then you have to analyze the needs first (e.g. the desirable
semantics that currently are avoided) All of then.
Adding one hack after the other is not the best approach.

[...]

Eventually the real solution is automatic inference, with the user
using explicit attributes at the top-level where they are desired, and
the compiler will take care of the rest.


T

[Ola Fosheim Grostad via Digitalmars-d]

On Sunday, 21 September 2014 at 23:04:22 UTC, H. S. Teoh via

Post by H. S. Teoh via Digitalmars-d
Eventually the real solution is automatic inference, with the
user
using explicit attributes at the top-level where they are
desired, and
the compiler will take care of the rest.

Yes, but you need a model of the semantics you are looking for.

[Kagamin via Digitalmars-d]

Post by Tofu Ninja via Digitalmars-d
[1] http://youtu.be/TH9VCN6UkyQ

The worst part is programmers unable to express their ideas in
written form.

[Dicebot via Digitalmars-d]

Post by Tofu Ninja via Digitalmars-d
There was a recent video[1] by Jonathan Blow about what he
would want in a programming language designed specifically for
game development. Go, Rust, and D were mentioned and his reason
for not wanting to use D is is that it is "too much like C++"
although he does not really go into it much and it was a very
small part of the video it still brings up some questions.
What I am curious is what are the worst parts of D? What sort
of things would be done differently if we could start over or
if we were designing a D3? I am not asking to try and bash D
but because it is helpful to know what's bad as well as good.
I will start off...
GC by default is a big sore point that everyone brings up
"is" expressions are pretty wonky
Libraries could definitely be split up better
What do you think are the worst parts of D?
[1] http://youtu.be/TH9VCN6UkyQ

There are so many it is hard to chose worst offenders.

[Manu via Digitalmars-d]

On 20 September 2014 22:39, Tofu Ninja via Digitalmars-d

There was a recent video[1] by Jonathan Blow about what he would want in a
programming language designed specifically for game development. Go, Rust,
and D were mentioned and his reason for not wanting to use D is is that it
is "too much like C++" although he does not really go into it much and it
was a very small part of the video it still brings up some questions.
What I am curious is what are the worst parts of D? What sort of things
would be done differently if we could start over or if we were designing a
D3? I am not asking to try and bash D but because it is helpful to know
what's bad as well as good.
I will start off...
GC by default is a big sore point that everyone brings up
"is" expressions are pretty wonky
Libraries could definitely be split up better
What do you think are the worst parts of D?
[1] http://youtu.be/TH9VCN6UkyQ

Personally, after years of use, my focus on things that really annoy
me has shifted away from problems with the language, and firmly
towards basic practicality and productivity concerns.
I'm for addressing things that bother the hell out of me every single
day. I should by all reason be more productive in D, but after 6 years
of experience, I find I definitely remain less productive, thanks
mostly to tooling and infrastructure.

1. Constant rejection of improvements because "OMG breaking change!".
Meanwhile, D has been breaking my code on practically every release
for years. I don't get this, reject changes that are deliberately
breaking changes which would make significant improvements, but allow
breaking changes anyway because they are bug fixes? If the release
breaks code, then accept that fact and make some real proper breaking
changes that make D substantially better! It is my opinion that D
adopters don't adopt D because it's perfect just how it is and they
don't want it to improve with time, they adopt D *because they want it
to improve with time*! That implies an acceptance (even a welcoming)
of breaking changes.

2. Tooling is still insufficient. I use Visual Studio, and while
VisualD is good, it's not great. Like almost all tooling projects,
there is only one contributor, and I think this trend presents huge
friction to adoption. Tooling is always factored outside of the D
community and their perceived realm of responsibility. I'd like to see
tooling taken into the core community and issues/bugs treated just as
seriously as issues in the compiler/language itself.

3. Debugging is barely ever considered important. I'd love to see a
concerted focus on making the debug experience excellent. Iain had a
go at GDB, I understand there is great improvement there. Sadly, we
recently lost the developer of Mago (a Windows debugger). There's lots
of work we could do here, and I think it's of gigantic impact.

4. 'ref' drives me absolutely insane. It seems so trivial, but 6 years
later, I still can't pass an rvalue->ref (been discussed endlessly),
create a ref local, and the separation from the type system makes it a
nightmare in generic code. This was a nuisance for me on day-1, and
has been grinding me down endlessly for years. It has now far eclipsed
my grudges with the GC/RC, or literally anything else about the
language on account of frequency of occurrence; almost daily.