www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Isn't it about time for D3?

reply Liam McGillivray <yoshi.pit.link.mario gmail.com> writes:
D is a language with much promise, but it still has many problems 
that prevent it from being the great replacement for C++ that it 
was always meant to be.

There have been many changes suggested over time to improve the 
language, but they were rejected as they would inevitably cause 
breaking changes.  I think that breaking changes are something to 
be careful about, and they can definitely be a nuisance to adapt 
to.  But they must happen once in a while for things to advance.

I think it's about time for D3 to start developing.  So many 
suggestions for language changes have accumulated by now so I 
think that it's time to introduce to introduce the next wave of 
breaking changes.
It's nice to see that there's a wiki page that documents the 
history of suggested language changes. I applaud the organization.
https://wiki.dlang.org/Language_design_discussions

I realize that there are people who want to continue using D as 
it is, but those people may continue to use D2. Putting the 
breaking changes in a separate branch ensures that DM won't lose 
current clients as they can just continue using D2 as they are. 
Even after D3 is stabilized, D2 could have continued support 
until nobody wants it.

In Lua (a language with a bigger past and hopefully smaller 
future than D), breaking changes are introduced in even minor 
versions.  While I do think that's excessively frequent, there 
are still users of Lua 5.1.  Making D3 doesn't mean that D2 has 
to die.

I feel like D3 would see significantly wider adoption than D2 
ever got, as long as it successfully solves the problems of D2.

Here are some ways that D3 can be an improvement of D2:
-Final by default
-A standard library that is effective with or without garbage 
collection

Even Andrei has admitted some issues with D when answering this 
Quora question:
https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why

Even if you don't want to release a D3 too soon, I think it 
definately makes sense to get started sooner rather than later.  
D3 should be developed for the same reason that D was first 
developed; to make a better programming language that learns from 
the problems of the one before.
Jun 10 2017
next sibling parent Seb <seb wilzba.ch> writes:
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:

 D is a language with much promise, but it still has many 
 problems that prevent it from being the great replacement for 
 C++ that it was always meant to be.

 [...]


FYI: There also has been a recent debate about developing a new 
version of Phobos 
(http://forum.dlang.org/post/volmdaxjihbkpbtplynj forum.dlang.org) to be able
to get rid of auto-decoding, make everything work nicely with  nogc and
allocators, fix design issues with ranges, cleanup messy packages (e.g.
std.traits), etc.

I think everyone on the forums here agrees about the problems, 
it's just not clear what the best course of action is as breaking 
changes are costly. Remember that there are still companies using 
D1 or Python 2 out there.
OTOH many people representing companies have already vouched here 
that they would love to see the annoyances fixed and something 
these issues are even blockers for their official D use at work 
...
Jun 10 2017
prev sibling next sibling parent bpr <brogoff gmail.com> writes:
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:

I'd be fascinated by a revised D like language, say D3 or 
whatever.


 Here are some ways that D3 can be an improvement of D2:
 -Final by default


Wow, after all that, this is it? I think final by default would 
be an improvement, and I wish it had gone through, but it's not a 
big enough deal to make a new language.


 -A standard library that is effective with or without garbage 
 collection


That's being worked on with D right now, isn't it?

If you're not going to be very bold, what's the point of a D3? 
Let's really change stuff!


 Structs, enums, and pattern matching, like Rust and ML
 Type follows name like Ada, Scala, Rust, ...
 Macros like Nim
 Parallel features from Chapel


I think it's a huge uphill battle for a new language these days, 
and that there's more to be gained from fixing the current D and 
others, but I encourage you to design the next D.
Jun 10 2017
prev sibling next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:

 D is a language with much promise, but it still has many 
 problems that prevent it from being the great replacement for 
 C++ that it was always meant to be.

 There have been many changes suggested over time to improve the 
 language, but they were rejected as they would inevitably cause 
 breaking changes.  I think that breaking changes are something 
 to be careful about, and they can definitely be a nuisance to 
 adapt to.  But they must happen once in a while for things to 
 advance.

 I think it's about time for D3 to start developing.  So many 
 suggestions for language changes have accumulated by now so I 
 think that it's time to introduce to introduce the next wave of 
 breaking changes.
 It's nice to see that there's a wiki page that documents the 
 history of suggested language changes. I applaud the 
 organization.
 https://wiki.dlang.org/Language_design_discussions

 I realize that there are people who want to continue using D as 
 it is, but those people may continue to use D2. Putting the 
 breaking changes in a separate branch ensures that DM won't 
 lose current clients as they can just continue using D2 as they 
 are. Even after D3 is stabilized, D2 could have continued 
 support until nobody wants it.

 In Lua (a language with a bigger past and hopefully smaller 
 future than D), breaking changes are introduced in even minor 
 versions.  While I do think that's excessively frequent, there 
 are still users of Lua 5.1.  Making D3 doesn't mean that D2 has 
 to die.

 I feel like D3 would see significantly wider adoption than D2 
 ever got, as long as it successfully solves the problems of D2.

 Here are some ways that D3 can be an improvement of D2:
 -Final by default
 -A standard library that is effective with or without garbage 
 collection

 Even Andrei has admitted some issues with D when answering this 
 Quora question:
 https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why

 Even if you don't want to release a D3 too soon, I think it 
 definately makes sense to get started sooner rather than later.
  D3 should be developed for the same reason that D was first 
 developed; to make a better programming language that learns 
 from the problems of the one before.


Dev resources are stretched thin as it is, I doubt the core team 
would go for it.  For example, the vast majority of the work on 
the main compiler frontend in the last year was done by one 
person, 3-5 if you're being generous:

https://github.com/dlang/dmd/graphs/contributors?from=2016-05-01&to=2017-06-10&type=c

I think we need to build that team up before we consider 
branching again.  While it has now been longer since the D2 
branch than from the beginning to D2, I get the impression the 
core team is nowhere near finished with D2, to the point where 
they want to branch again.

While I personally think a D3 branch now would make sense on the 
technical merits, I doubt we're at an organizational state where 
we can afford it, ie not enough manpower.
Jun 10 2017
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 11 June 2017 at 00:06:13 UTC, Joakim wrote:

 Dev resources are stretched thin as it is, I doubt the core 
 team would go for it.


I think dev resources are thin because of mismanagement by the 
core team failing to attract and retain contributors. Part of 
this mismanagement is a really discouraging attitude toward 
positive yet breaking change; I propose that mere willingness to 
shake up the status quo would help to solve the resource shortage.
Jun 10 2017
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Adam D. Ruppe wrote:


 On Sunday, 11 June 2017 at 00:06:13 UTC, Joakim wrote:

 Dev resources are stretched thin as it is, I doubt the core team would 
 go for it.


 I think dev resources are thin because of mismanagement by the core team 
 failing to attract and retain contributors. Part of this mismanagement is 
 a really discouraging attitude toward positive yet breaking change; I 
 propose that mere willingness to shake up the status quo would help to 
 solve the resource shortage.


actually, some time ago i proposed to create "experimental and breaking 
language changes" subforum, where people can go with their wild ideas, and 
other people can post patches/builds with those (or other) ideas 
imlemented/half-implemented.

this way we can gather some feedback from someone who is really using new 
feature, and have a better vision if it worth further time investments or 
not. 'cause having a live compiler with new feature to play with is not the 
same as simply dicussing the possible feature in NG. i maintain my private 
fork of dmd/druntime/phobos, and this is the way i evaluate features: just 
add what i can, and then see if i'll start using it in my code. if not, the 
feature is cutted, otherwise it is retained.

and ah, building dmd from sources is not something many people want/can to 
do. sure, downloading binaries from random people over the net is not the 
safest thing to do, but if there will be patch+binary combos, it may work.

i.e. i see that "experimental" subforum as a place for ideas *and* 
implementations. and implementors can provide built binaries for people to 
play, or other people can build binaries ('cause if you built it for 
yourself, why don't share it with others?).

i know that this forum is actually a newsgroup, and it can't host files. 
but i believe that this problem can be solved -- either by using some 
simple js-free (for download; yeah, there are such things! ;-) service to 
host binaries, or by some other means.
Jun 10 2017
next sibling parent reply Mike B Johnson <Mikey Ikes.com> writes:
On Sunday, 11 June 2017 at 00:37:09 UTC, ketmar wrote:

 Adam D. Ruppe wrote:


 On Sunday, 11 June 2017 at 00:06:13 UTC, Joakim wrote:

 Dev resources are stretched thin as it is, I doubt the core 
 team would go for it.


 I think dev resources are thin because of mismanagement by the 
 core team failing to attract and retain contributors. Part of 
 this mismanagement is a really discouraging attitude toward 
 positive yet breaking change; I propose that mere willingness 
 to shake up the status quo would help to solve the resource 
 shortage.


 actually, some time ago i proposed to create "experimental and 
 breaking language changes" subforum, where people can go with 
 their wild ideas, and other people can post patches/builds with 
 those (or other) ideas imlemented/half-implemented.

 this way we can gather some feedback from someone who is really 
 using new feature, and have a better vision if it worth further 
 time investments or not. 'cause having a live compiler with new 
 feature to play with is not the same as simply dicussing the 
 possible feature in NG. i maintain my private fork of 
 dmd/druntime/phobos, and this is the way i evaluate features: 
 just add what i can, and then see if i'll start using it in my 
 code. if not, the feature is cutted, otherwise it is retained.

 and ah, building dmd from sources is not something many people 
 want/can to do. sure, downloading binaries from random people 
 over the net is not the safest thing to do, but if there will 
 be patch+binary combos, it may work.

 i.e. i see that "experimental" subforum as a place for ideas 
 *and* implementations. and implementors can provide built 
 binaries for people to play, or other people can build binaries 
 ('cause if you built it for yourself, why don't share it with 
 others?).

 i know that this forum is actually a newsgroup, and it can't 
 host files. but i believe that this problem can be solved -- 
 either by using some simple js-free (for download; yeah, there 
 are such things! ;-) service to host binaries, or by some other 
 means.


Yeah, sounds good, because to make progress, progress has to be 
made. Most people are very shortsighted and live in a fear based 
mentality. Mention any type of change and they nearly shit 
themselves and never actually think about the consequence of 
those changes. They just assume it means change and it's 
something they can't handle.

Having an "experimental" D allows those crazy and potentially 
"mind altering" advancements to be worked on, advanced, and 
polished. It takes time for ideas to grow(because, ultimately, it 
involves learning and learning takes time).

So, the good experimental changes will eventually be adopted. 
Without such a mechanism, they can't EVER be. The problem is that 
only the core people of D actually get to decide what is good and 
they tend to push through changes that haven't been well 
tested(regardless of what they think, D is a prime example by all 
the miscalculations as is C).

Most people fear growth because growth requires change and change 
ventures in to the unknown... The unknown is where all the good 
shit lies and the breakthrough is when someone brings the unknown 
in to the known.
Jun 10 2017
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Mike B Johnson wrote:


 Yeah, sounds good, because to make progress, progress has to be made. 
 Most people are very shortsighted and live in a fear based mentality. 
 Mention any type of change and they nearly shit themselves and never 
 actually think about the consequence of those changes. They just assume 
 it means change and it's something they can't handle.

 Having an "experimental" D allows those crazy and potentially "mind 
 altering" advancements to be worked on, advanced, and polished. It takes 
 time for ideas to grow(because, ultimately, it involves learning and 
 learning takes time).


yeah. this is exactly the mentality i want to fight with. in my opition, 
having such forum "officially blessed" will encourage people to experiment. 
or at least i hope so. ;-)
Jun 10 2017
parent reply Mike B Johnson <Mikey Ikes.com> writes:
On Sunday, 11 June 2017 at 06:14:43 UTC, ketmar wrote:

 Mike B Johnson wrote:


 Yeah, sounds good, because to make progress, progress has to 
 be made. Most people are very shortsighted and live in a fear 
 based mentality. Mention any type of change and they nearly 
 shit themselves and never actually think about the consequence 
 of those changes. They just assume it means change and it's 
 something they can't handle.

 Having an "experimental" D allows those crazy and potentially 
 "mind altering" advancements to be worked on, advanced, and 
 polished. It takes time for ideas to grow(because, ultimately, 
 it involves learning and learning takes time).


 yeah. this is exactly the mentality i want to fight with. in my 
 opition, having such forum "officially blessed" will encourage 
 people to experiment. or at least i hope so. ;-)


It's an uphill battle. You are fighting human 
nature/evolution/ignorance ;/ The good news is that humans are 
good at mountain climbing when they want to be.
Jun 11 2017
parent ketmar <ketmar ketmar.no-ip.org> writes:
Mike B Johnson wrote:


 On Sunday, 11 June 2017 at 06:14:43 UTC, ketmar wrote:

 Mike B Johnson wrote:


 Yeah, sounds good, because to make progress, progress has to be made. 
 Most people are very shortsighted and live in a fear based mentality. 
 Mention any type of change and they nearly shit themselves and never 
 actually think about the consequence of those changes. They just assume 
 it means change and it's something they can't handle.

 Having an "experimental" D allows those crazy and potentially "mind 
 altering" advancements to be worked on, advanced, and polished. It 
 takes time for ideas to grow(because, ultimately, it involves learning 
 and learning takes time).


 yeah. this is exactly the mentality i want to fight with. in my opition, 
 having such forum "officially blessed" will encourage people to 
 experiment. or at least i hope so. ;-)


 It's an uphill battle. You are fighting human nature/evolution/ignorance 
 ;/ The good news is that humans are good at mountain climbing when they 
 want to be.


yeah. i don't have enough energy to keep a *real* fight going, but i at 
least poping up with my "experimental forum" idea from time to time. i'm in 
no hurry, and i'm sure that slow, but constant efforts will won the battle. 
10 years, 100 years, 1000 years... as i said, i'm in no hurry at all. ;-)
Jun 11 2017
prev sibling parent reply Seb <seb wilzba.ch> writes:
On Sunday, 11 June 2017 at 00:37:09 UTC, ketmar wrote:

 Adam D. Ruppe wrote:

 I think dev resources are thin because of mismanagement by the 
 core team failing to attract and retain contributors. Part of 
 this mismanagement is a really discouraging attitude toward 
 positive yet breaking change; I propose that mere willingness 
 to shake up the status quo would help to solve the resource 
 shortage.




+1


 actually, some time ago i proposed to create "experimental and 
 breaking language changes" subforum, where people can go with 
 their wild ideas, and other people can post patches/builds with 
 those (or other) ideas imlemented/half-implemented.


That's called a feature-branch ;-)
The nightlies and CI scripts fully support feature branches since 
a couple of months (i.e. the same branch is checked out on all 
dmd, druntime and phobos).
Currently it's only used for `scope` and `newCTFE`:

http://nightlies.dlang.org

Currently not much is happening on these feature branches and 
thus Martin is running the builds on demand by hand.
However, from a technical point of view, it would be rather easy 
to use this for more feature branches ;-)
Jun 10 2017
parent ketmar <ketmar ketmar.no-ip.org> writes:
Seb wrote:


 On Sunday, 11 June 2017 at 00:37:09 UTC, ketmar wrote:

 Adam D. Ruppe wrote:

 I think dev resources are thin because of mismanagement by the core 
 team failing to attract and retain contributors. Part of this 
 mismanagement is a really discouraging attitude toward positive yet 
 breaking change; I propose that mere willingness to shake up the status 
 quo would help to solve the resource shortage.




 +1


 actually, some time ago i proposed to create "experimental and breaking 
 language changes" subforum, where people can go with their wild ideas, 
 and other people can post patches/builds with those (or other) ideas 
 imlemented/half-implemented.


 That's called a feature-branch ;-)


not everybody in the world is github-centric.
Jun 10 2017
prev sibling parent reply Cym13 <cpicard openmailbox.org> writes:
On Sunday, 11 June 2017 at 00:22:50 UTC, Adam D. Ruppe wrote:

 On Sunday, 11 June 2017 at 00:06:13 UTC, Joakim wrote:

 Dev resources are stretched thin as it is, I doubt the core 
 team would go for it.


 I think dev resources are thin because of mismanagement by the 
 core team failing to attract and retain contributors. Part of 
 this mismanagement is a really discouraging attitude toward 
 positive yet breaking change; I propose that mere willingness 
 to shake up the status quo would help to solve the resource 
 shortage.


Building on that: 82% of patches for Mozilla Firefox are accepted 
at first sight. Analysis of the reviews shows that the developper 
himself often comes back to his patch to correct it before 
resubmitting it. Such corrections often are due to style because 
style isn't generally blocking. That said, having worked on 
Firefox's codebase a fair amount of time I must say that they 
have one of the cleanest C++ codebase I've ever seen.

The whitepaper is here [1], named "The influence of non-technical 
factors on code review". I strongly recommend reading it, 
especially for you Walter and Andrei as I think you might like 
some of its insights.

There again we are not Mozilla, Phobos is a standard library, a 
compiler doesn't release every 3 months. But one thing is sure, 
if Firefox can accept 82% of patches at first sight, if 60% of 
all patches end up being integrated without resubmission, then 
the projet size isn't an issue. And before such evidence I am 
definitely not convinced that it should be hard to introduce a 
change. What should be hard is introducing a bad one.

(Then again I'm all talk and not wanting to take care of the 
matter myself so I'm not expecting anything to change just from 
this post.)

[1]: https://cs.uwaterloo.ca/~rtholmes/papers/wcre_2013_baysal.pdf
Jun 11 2017
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/11/17 5:14 AM, Cym13 wrote:

 Building on that: 82% of patches for Mozilla Firefox are accepted at 
 first sight.


Thanks for referring the paper, I'll read it on the plane. Facebook's 
rate would be probably comparable. An important detail: is that the rate 
for internal developers or public contributors? Couldn't get a 
definitive answer by skimming the paper. -- Andrei
Jun 11 2017
next sibling parent Cym13 <cpicard openmailbox.org> writes:
On Sunday, 11 June 2017 at 12:22:02 UTC, Andrei Alexandrescu 
wrote:

 On 6/11/17 5:14 AM, Cym13 wrote:

 Building on that: 82% of patches for Mozilla Firefox are 
 accepted at first sight.


 Thanks for referring the paper, I'll read it on the plane. 
 Facebook's rate would be probably comparable. An important 
 detail: is that the rate for internal developers or public 
 contributors? Couldn't get a definitive answer by skimming the 
 paper. -- Andrei


I'm not certain either. For Webkit they took all patches without 
discriminating by origin so I think they did the same for 
Firefox. The development plateform is public so it would be more 
work to filter commits, therefore I don't think they did.
Jun 11 2017
prev sibling parent Cym13 <cpicard openmailbox.org> writes:
On Sunday, 11 June 2017 at 12:22:02 UTC, Andrei Alexandrescu 
wrote:

 On 6/11/17 5:14 AM, Cym13 wrote:

 Building on that: 82% of patches for Mozilla Firefox are 
 accepted at first sight.


 Thanks for referring the paper, I'll read it on the plane. 
 Facebook's rate would be probably comparable. An important 
 detail: is that the rate for internal developers or public 
 contributors? Couldn't get a definitive answer by skimming the 
 paper. -- Andrei


Found it: the paper I linked focuses more on webkit, the case of 
firefox is detailed in a previous paper [1]. They did choose to 
focus on core developers defining them as having proposed 100+ 
patches. This point of the methodology is explained in more 
details in section IV of the paper.

[1]: 
https://plg.uwaterloo.ca/~migod/papers/2012/wcre12-olgaAlexReid.pdf
Jun 11 2017
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Liam McGillivray wrote:


 I feel like D3 would see significantly wider adoption than D2 ever got, 
 as long as it successfully solves the problems of D2.


..and it actually should be D1.5, not D3. ;-) 'cause D3 implies even more 
features, and i feel that the way to get The Perfect D (sorry! ;-) is 
trying to cut all the features that aren't strictly necessary (including 
fat-free stdlib too: i see stdlib as a part of the language).
Jun 10 2017
parent reply Liam McGillivray <yoshi.pit.link.mario gmail.com> writes:
On Sunday, 11 June 2017 at 00:27:06 UTC, ketmar wrote:

 ..and it actually should be D1.5, not D3. ;-) 'cause D3 implies 
 even more features, and i feel that the way to get The Perfect 
 D (sorry! ;-) is trying to cut all the features that aren't 
 strictly necessary (including fat-free stdlib too: i see stdlib 
 as a part of the language).


D1.5? What?  This has nothing to do with D1.  D3 would be forked 
from D2.  The reason that it would be considered a major version 
is because it introduces breaking changes.  As far as I know, D2 
hasn't been allowed breaking changes since stabilization June 
2010.
Jun 10 2017
next sibling parent reply Suliman <evermind live.ru> writes:
There is already something like D3 exists. 
https://github.com/VoltLang
Jun 10 2017
parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Sunday, 11 June 2017 at 05:03:10 UTC, Suliman wrote:

 There is already something like D3 exists. 
 https://github.com/VoltLang


https://github.com/VoltLang/Watt/blob/97507a202250af96560317f84c29cb2248ae588b/src/watt/algorithm.volt#L37-L91

I don't think so.
Jun 10 2017
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Liam McGillivray wrote:


 On Sunday, 11 June 2017 at 00:27:06 UTC, ketmar wrote:

 ..and it actually should be D1.5, not D3. ;-) 'cause D3 implies even 
 more features, and i feel that the way to get The Perfect D (sorry! ;-) 
 is trying to cut all the features that aren't strictly necessary 
 (including fat-free stdlib too: i see stdlib as a part of the language).


 D1.5? What?  This has nothing to do with D1. 


and D1.5 too. sure it should be forked from D2, and then it should be made 
*smaller*. which, essentially, makes it D1.5, not D3. besides, it will be 
very fun explaining people that we have D1, then D2, and the newest version 
is D1.5. people will blog/tweet this, for sure. free PR!
Jun 10 2017
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 11 June 2017 at 05:24:25 UTC, ketmar wrote:

 and D1.5 too. sure it should be forked from D2, and then it 
 should be made *smaller*. which, essentially, makes it D1.5, 
 not D3. besides, it will be very fun explaining people that we


D--?

Out of curiosity; wouldn't it be better to start with one of the 
alternative compilers that are being worked on (SDC or others), 
or are they no longer active?
Jun 11 2017
parent ketmar <ketmar ketmar.no-ip.org> writes:
Ola Fosheim Grøstad wrote:


 On Sunday, 11 June 2017 at 05:24:25 UTC, ketmar wrote:

 and D1.5 too. sure it should be forked from D2, and then it should be 
 made *smaller*. which, essentially, makes it D1.5, not D3. besides, it 
 will be very fun explaining people that we


 D--?

 Out of curiosity; wouldn't it be better to start with one of the 
 alternative compilers that are being worked on (SDC or others), or are 
 they no longer active?


to remove features, it is nice to *have* those features first. and there 
are no other feature-complete frontends besides dmdfe.
Jun 11 2017
prev sibling next sibling parent James Hofmann <jhofmann 321f.net> writes:
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:

 I realize that there are people who want to continue using D as 
 it is, but those people may continue to use D2. Putting the 
 breaking changes in a separate branch ensures that DM won't 
 lose current clients as they can just continue using D2 as they 
 are. Even after D3 is stabilized, D2 could have continued 
 support until nobody wants it.


Here is my suggestion for how to migrate into D3 well, if it were 
to be done:

First define a "Small D2". The goal of this language is to not 
really be that much smaller(it could still leave in most of the 
language, in fact), but to sweep up all the changes breaking with 
D2 into a form that's clearly less flexible while still being 
palatable for the majority of modules. It's allowed to be 
intentionally clumsy and regressive in some ways so that it can 
be forward-looking later, but not so much so that people don't 
want to write in it.

Small D2 is given the freedom to do things like regress standard 
library functions back into hardcoded compiler behaviors, to be 
more restrictive, to allow less ambiguity, and to generally 
follow with existing idioms but break the things that needed 
breaking and leave out the parts that didn't work. The new stuff 
of Small D2 would be "one-trick-pony" features that bottleneck 
what can be expressed into a "library" that is actually a 
compiler hack, or "new syntax" that is actually fake and only 
allows arbitrary expressions that are already possible in other 
ways.

Most importantly, Small D2 retains compatibility with regular 
("big") D2 modules, so codebases can be migrated into Small D2 
piecemeal, while leaving a small remainder to be migrated in a 
larger way when D3 rolls out. In essence, Small D2 allows the 
underlying formulation of D to be challenged, but it actually 
relies on regular D2 constructs internally, so iteration on 
design can go faster than if we "did it for real". And because 
Small D2 gives people a taste of new stuff, it will have some 
instant appeal: People should want to write new code in it, even 
knowing that it's a hack and less powerful.

Small D2 would be the debate platform for what the "core" of D 
is. Then, D3 is Small D2 with everything "done for real" this 
time. Small D2 code migrates forward seamlessly and can continue 
operating as if nothing happened. The rest of it is considered 
breaking.
Jun 10 2017
prev sibling next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:

 I realize that there are people who want to continue using D as 
 it is, but those people may continue to use D2.


Well, no thanks.
The very same strategy halved the community for D1/D2 split and 
almost killed D.
Jun 11 2017
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Guillaume Piolat wrote:


 On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:

 I realize that there are people who want to continue using D as it is, 
 but those people may continue to use D2.


 Well, no thanks.
 The very same strategy halved the community for D1/D2 split and almost 
 killed D.


as you can see, D is alive and kicking, and nothing disasterous or fatal
happens.
Jun 11 2017
next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Sunday, 11 June 2017 at 17:59:54 UTC, ketmar wrote:

 Well, no thanks.
 The very same strategy halved the community for D1/D2 split 
 and almost killed D.


 as you can see, D is alive and kicking, and nothing disasterous 
 or fatal happens.


https://forum.dlang.org/search?q=%22D2%22+destroyed+author%3AWalter+author%3ABright&search=Search
Jun 11 2017
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Guillaume Piolat wrote:


 On Sunday, 11 June 2017 at 17:59:54 UTC, ketmar wrote:

 Well, no thanks.
 The very same strategy halved the community for D1/D2 split and almost 
 killed D.


 as you can see, D is alive and kicking, and nothing disasterous or fatal 
 happens.


 https://forum.dlang.org/search?q=%22D2%22+destroyed+author%3AWalter+author%3ABright&search=Search


so what? "nearly destroyed" != "destroyed". as i said, D is alive and ok, 
nothing fatal happens. backing fear of changes with "last time it almost 
destroyed us" won't do any good in the long term: it will ultimately end 
with having no changes at all, D will stagnate and die.

changing is a natural thing for evolution, even breaking change. evaluating 
was what done wrong/inoptimal, and improving on that it the thing that will 
keep D not only alive, but will make it better and better. otherwise, 
accumulated legacy will inevitably turn D into another C++, and somebody 
will create E (or something ;-). why don't create E outselves, and call it 
D3 instead?
Jun 11 2017
parent reply solidstate1991 <laszloszeremi outlook.com> writes:
On Sunday, 11 June 2017 at 22:53:44 UTC, ketmar wrote:

 so what? "nearly destroyed" != "destroyed". as i said, D is 
 alive and ok, nothing fatal happens. backing fear of changes 
 with "last time it almost destroyed us" won't do any good in 
 the long term: it will ultimately end with having no changes at 
 all, D will stagnate and die.

 changing is a natural thing for evolution, even breaking 
 change. evaluating was what done wrong/inoptimal, and improving 
 on that it the thing that will keep D not only alive, but will 
 make it better and better. otherwise, accumulated legacy will 
 inevitably turn D into another C++, and somebody will create E 
 (or something ;-). why don't create E outselves, and call it D3 
 instead?


E already exists 
(https://en.wikipedia.org/wiki/E_(programming_language) + 
AmigaE), two things having the same name often doom one of them 
into obscurity (see SDLang, which originally was called SDL).

There were already a few changes in the language (use of static 
imports instead of directly accessing functions/libraries, etc), 
just as we're adding to the language, we can remove rarely used 
functions by first making them deprecated, then removing them 
altogether as time passes on.
Jun 11 2017
parent ketmar <ketmar ketmar.no-ip.org> writes:
solidstate1991 wrote:


 E already exists (https://en.wikipedia.org/wiki/E_(programming_language) 
 + AmigaE), two things having the same name often doom one of them into 
 obscurity (see SDLang, which originally was called SDL).


and there were several "D"s too. ;-)


 There were already a few changes in the language (use of static imports 
 instead of directly accessing functions/libraries, etc), just as we're 
 adding to the language, we can remove rarely used functions by first 
 making them deprecated, then removing them altogether as time passes on.


sometimes it is hard or even impossible to change something and keep old 
feature still working. it also require considerably more efforts to support 
old and new feature set simultaneously. while D2 can continue evolving (and 
it surely will!), having D3, where keeping old code working is not a 
concern, can be useful.

nobody says that we should abandon D2 tomorrow and switch everything to D3. 
it's more about exploring new ways without constant pressure of "don't 
break the code" mantra.

don't get me wrong, tho: "don't break the code" is good. but it limits 
possible ways D can evolve (or greatly slows it all down). D3 can be 
"experimental research project", where some of the dreams can come true. it 
may won't even reach the state where it will replace D2, instead D2 may 
adopt some D3 features, and D3 will be scrapped (or restarted). there is 
nothing wrong with it. also, i don't expect D3 to be developed in "full 
speed" too.
Jun 11 2017
prev sibling parent reply Sebastien Alaiwan <ace17 free.fr> writes:
On Sunday, 11 June 2017 at 17:59:54 UTC, ketmar wrote:

 Guillaume Piolat wrote:


 On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray 
 wrote:

 I realize that there are people who want to continue using D 
 as it is, but those people may continue to use D2.


 Well, no thanks.
 The very same strategy halved the community for D1/D2 split 
 and almost killed D.


 as you can see, D is alive and kicking, and nothing disasterous 
 or fatal happens.


Yes, but could it have been a lot more alive and kicking, hadn't 
we shot ourselves in the foot with this D1/D2 split?
Jun 12 2017
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Sebastien Alaiwan wrote:


 On Sunday, 11 June 2017 at 17:59:54 UTC, ketmar wrote:

 Guillaume Piolat wrote:


 On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:

 I realize that there are people who want to continue using D as it is, 
 but those people may continue to use D2.


 Well, no thanks.
 The very same strategy halved the community for D1/D2 split and almost 
 killed D.


 as you can see, D is alive and kicking, and nothing disasterous or fatal 
 happens.


 Yes, but could it have been a lot more alive and kicking, hadn't we shot 
 ourselves in the foot with this D1/D2 split?


this question has no answer. can we do better if we will do everything 
right on the first try? of course!
Jun 12 2017
parent reply Sebastien Alaiwan <ace17 free.fr> writes:
On Tuesday, 13 June 2017 at 06:56:14 UTC, ketmar wrote:

 Sebastien Alaiwan wrote:


 On Sunday, 11 June 2017 at 17:59:54 UTC, ketmar wrote:

 Guillaume Piolat wrote:


 On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray 
 wrote:

 I realize that there are people who want to continue using 
 D as it is, but those people may continue to use D2.


 Well, no thanks.
 The very same strategy halved the community for D1/D2 split 
 and almost killed D.


 as you can see, D is alive and kicking, and nothing 
 disasterous or fatal happens.


 Yes, but could it have been a lot more alive and kicking, 
 hadn't we shot ourselves in the foot with this D1/D2 split?


 this question has no answer. can we do better if we will do 
 everything right on the first try? of course!


My point precisely was that "not splitting D1/D2" might 
correspond to "doing things right".
Jun 13 2017
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Sebastien Alaiwan wrote:


 My point precisely was that "not splitting D1/D2" might correspond to 
 "doing things right".


"not splitting" here means "we're stuck with D1". deprecation cycle of 
several years (not counting the time required to actually *start* the 
process) means "no evolution".

i must make myself clear here, i guess: i value "good language" way more 
than "stable language". i absolutely don't mind fixing my code if it makes 
it better/more clear/etc. while it's hard to sell "constantly evolving" 
language to Big Enterprise Wheels, not making breaking changes means 
cloning worst C++ feature. ;-)
Jun 13 2017
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 13 June 2017 at 12:23:19 UTC, ketmar wrote:

 Sebastien Alaiwan wrote:


 My point precisely was that "not splitting D1/D2" might 
 correspond to "doing things right".


 "not splitting" here means "we're stuck with D1". deprecation 
 cycle of several years (not counting the time required to 
 actually *start* the process) means "no evolution".

 i must make myself clear here, i guess: i value "good language" 
 way more than "stable language". i absolutely don't mind fixing 
 my code if it makes it better/more clear/etc. while it's hard 
 to sell "constantly evolving" language to Big Enterprise 
 Wheels, not making breaking changes means cloning worst C++ 
 feature. ;-)


Companies clearly value C++'s backwards compatibility. However, 
if there's one lesson from the D1/D2 or the Python 2/Python 3 
split, it's that it's hugely disruptive (so much so that I find 
the idea of D3, at the moment, to be such an obviously terrible 
idea that I really wanted to avoid commenting on this thread). 
Nevertheless, C++ is still a constantly evolving language. C++14 
looks a lot different from C++98. Maintaining backwards 
compatibility, however, has significantly increased the 
complexity.

Thus, I think there's a trade-off. Breaking changes that improve 
the language may be good in certain circumstances, but 
Walter/Andrei should try to get the buy-in from big D users 
beforehand (even with a depreciation cycle). Requiring some kind 
of broad support from big D users would mean that breaking 
changes only happen if the the costs of breaking changes are 
smaller than the improvement to the language.
Jun 13 2017
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 13 June 2017 at 13:29:45 UTC, jmh530 wrote:


 Companies clearly value C++'s backwards compatibility. However, 
 if there's one lesson from the D1/D2 or the Python 2/Python 3 
 split, it's that it's hugely disruptive (so much so that I find


The D1/D2 split was actually a unifier. It was the Phobos/Tango 
divide that was the problem. D2 healed that rift, brought us a 
single runtime that both libraries could share, improved Phobos, 
and was relatively easy for most projects to transition to 
(Sociomantic's experience was not common), and D1 was eventually 
retired. We're all better off for it. A vastly different 
situation than what happened with Python, where you find 2.x 
releases continuing on and some projects requiring one or the 
other.

That said, at this stage, I can't imagine a D2/D3 transition 
being anything other than negatively disruptive.
Jun 13 2017
prev sibling next sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
Before even contemplating a big disrupting language split like 
proposed by the OP, wouldn't it first more appropriate to write a 
nice article, DIP, blog, whatever, listing the defects of the 
current language that can not be solved by progressive evolution?
I haven't the impression that the *language* itself suffer from 
so big flaws that it would warrant to fork it in a way that will 
lead to a lot frustration and bewilderment.
D is not perfect, no question, but it is not in a state that 
would jusrify such a harsh approach.
Jun 13 2017
next sibling parent reply crimaniak <crimaniak gmail.com> writes:
On Tuesday, 13 June 2017 at 17:57:14 UTC, Patrick Schluter wrote:


 I haven't the impression that the *language* itself suffer from 
 so big flaws that it would warrant to fork it in a way that 
 will lead to a lot frustration and bewilderment.


  I have the same opinion. Raw libraries, poor documentation and 
infrastructure are much more problematic. If it depended on me, I 
would declare an embargo on language changes and throw all the 
forces to eliminate the problems of infrastructure and libraries.
Jun 13 2017
parent ketmar <ketmar ketmar.no-ip.org> writes:
crimaniak wrote:


 If it depended on me, I would declare an embargo on language changes


that's why we (me, and others like me ;-) need D3. i don't need "better 
phobos", for example ('cause i'm trying to aboid using phobos anyway), but 
i really need named arguments (`foo(a:42, b:"hello")`). i want '=>' to be 
usable for any method/free function, not only for lambdas. i want $-expands 
in mixin strings. warnings on unary minus on byte/short types (do you know 
that D doesn't do int promition in this case, and C does? it bites me 
several times!). i want `foreach_reverse` to be replaced with `foreach 
(auto a; b; reverse)` (and *require* type, modifier or `auto` there). i 
want optional `ref` and `out` marks for function *calls*. i want... i want 
alot of things, i'm not even started yet. especially not started to talk 
about breaking changes. i cannot do that now (i have my private fork of 
dmd), 'cause i need to keep compatibility with vanilla, and i have zero 
hopes to see it all introduced in D2 (language stability, etc.). with D2, 
i'll have a chance to bring 'em on a table.
Jun 13 2017
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Patrick Schluter wrote:


 Before even contemplating a big disrupting language split like proposed 
 by the OP, wouldn't it first more appropriate to write a nice article, 
 DIP, blog, whatever, listing the defects of the current language that can 
 not be solved by progressive evolution?
 I haven't the impression that the *language* itself suffer from so big 
 flaws that it would warrant to fork it in a way that will lead to a lot 
 frustration and bewilderment.
 D is not perfect, no question, but it is not in a state that would 
 jusrify such a harsh approach.


the main reason for D3 is not language changes, but workarounding "don't 
break user code" thingy. it is completely impossible to experiment freely 
or introduce breaking changes in D2 (for a reason, there is nothing bad in it).
Jun 13 2017
parent reply Wulfklaue <wulfklaue wulfklaue.com> writes:
On Tuesday, 13 June 2017 at 20:51:37 UTC, ketmar wrote:

 Patrick Schluter wrote:
 the main reason for D3 is not language changes, but 
 workarounding "don't break user code" thingy. it is completely 
 impossible to experiment freely or introduce breaking changes 
 in D2 (for a reason, there is nothing bad in it).


Can you actually show us examples of what you think needs to 
break?

Maybe i am too new to D but beyond a few oddities ( std.array 
needed for string manipulation, ... ) i see not a lot wrong.

Do not underestimate the effect that rewriting a standard library 
has on a language. Beyond sucking resources away ( D is not a 
very big community project like Rust ).

Frankly one of the reasons why i ended up with D. It has the 
kitchen and sink, has everything from generics, meta programming 
and beyond. And the most import factor, it is STABLE. I am 
working on a big project that needs stability for the next 10+ 
years. This D3 discussion is discouraging to read.

D its flaws are the Phobos documentation layout ( what is 
partially solved by the Library documentation ), somewhat lacking 
support on the editors, and other points. Mostly to do because of 
the small community/lack of full time paid programmers.

So call me confused as to what is missing and needs such radical 
changes? Because i can tell clearly from reading past forums, the 
whole D1/D2 came up in so much topics it actually made me look 
first into other languages. A D3 discussion is silly given the 
history of the language.

Unless i am wrong there seem to be only one or two people 
actually pushing this D3 idea...
Jun 14 2017
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 14/06/2017 8:28 AM, Wulfklaue wrote:

 On Tuesday, 13 June 2017 at 20:51:37 UTC, ketmar wrote:

 Patrick Schluter wrote:
 the main reason for D3 is not language changes, but workarounding 
 "don't break user code" thingy. it is completely impossible to 
 experiment freely or introduce breaking changes in D2 (for a reason, 
 there is nothing bad in it).


 
 Can you actually show us examples of what you think needs to break?
 
 Maybe i am too new to D but beyond a few oddities ( std.array needed for 
 string manipulation, ... ) i see not a lot wrong.
 
 Do not underestimate the effect that rewriting a standard library has on 
 a language. Beyond sucking resources away ( D is not a very big 
 community project like Rust ).
 
 Frankly one of the reasons why i ended up with D. It has the kitchen and 
 sink, has everything from generics, meta programming and beyond. And the 
 most import factor, it is STABLE. I am working on a big project that 
 needs stability for the next 10+ years. This D3 discussion is 
 discouraging to read.
 
 D its flaws are the Phobos documentation layout ( what is partially 
 solved by the Library documentation ), somewhat lacking support on the 
 editors, and other points. Mostly to do because of the small 
 community/lack of full time paid programmers.
 
 So call me confused as to what is missing and needs such radical 
 changes? Because i can tell clearly from reading past forums, the whole 
 D1/D2 came up in so much topics it actually made me look first into 
 other languages. A D3 discussion is silly given the history of the 
 language.
 
 Unless i am wrong there seem to be only one or two people actually 
 pushing this D3 idea...


Don't worry too much about "D3". While I also want a "D3" it won't be a 
big technical change, much more likely a philosophical change than 
anything else.

In other words, except for the odd change like final by default for 
classes(eww), there isn't anything that needs to change for D2. Only 
smaller improvements which are well worth breaking current semantics.
Jun 14 2017
prev sibling next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
Wulfklaue wrote:


 On Tuesday, 13 June 2017 at 20:51:37 UTC, ketmar wrote:

 Patrick Schluter wrote:
 the main reason for D3 is not language changes, but workarounding "don't 
 break user code" thingy. it is completely impossible to experiment 
 freely or introduce breaking changes in D2 (for a reason, there is 
 nothing bad in it).


 Can you actually show us examples of what you think needs to break?


it would be a very long post. ;-) i scratched it a little above, though. my 
private dmd fork has 100+ patches only to dmd itself, for example, and some 
are disruptive enough that alot of my code is marked with `module a is aliced;`.


 Frankly one of the reasons why i ended up with D. It has the kitchen and 
 sink, has everything from generics, meta programming and beyond. And the 
 most import factor, it is STABLE. I am working on a big project that 
 needs stability for the next 10+ years. This D3 discussion is 
 discouraging to read.


and one of mine reasons was "yay, it is relatively new, unencumbered with 
alot of legacy, and *evolving*!" none of it (our reasoning) is better over 
another. ;-)


 D its flaws are the Phobos documentation layout


one of the things i absolutely don't care about, for example. ;-) besides, 
dpldocs rox.


 So call me confused as to what is missing and needs such radical changes?


evolving. something very opposite to "stability", as expected by some 
enterprise users. remember, not all D users are enterprise users. ;-) some 
of us (me!) came here 'cause D is fun, not 'cause D is "stable", and we may 
value stability much less than other kinds of users.


 Unless i am wrong there seem to be only one or two people actually 
 pushing this D3 idea...


as for me, i'm not "pushing" it, i am merely "supporting" it. just to make 
sure that other optinions besides "no, we don't need D3" are not seeing as 
non-existant only due to their bearers being silent. ;-)
Jun 14 2017
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wednesday, June 14, 2017 07:28:34 Wulfklaue via Digitalmars-d wrote:

 Unless i am wrong there seem to be only one or two people
 actually pushing this D3 idea...


It comes up periodically, because there's some change that someone wants
that will never make it into D2. Historically, it's the response to most
anyone being told that what they want won't make it into D2, and actually,
it used to come up quite a bit, but it rarely comes up now. Sure, there are
some changes that we'd probably make to the language if we were doing things
from scratch or willing to just break every existing D program, but I think
that you'd have a hard time getting folks to agree on a list of what would
be changed under those circumstances, and for the most part, I think that
folks will agree that it's not worth it at this point - certainly, I think
that you're going to have a hard time finding any core contributors who
think that starting D3 would be a good idea at this point. And I'd be
shocked if anyone managed to convince Walter or Andrei that it was a good
idea.

Now, there are changes in Phobos which a number of us would like to see that
you'll see a much greater consensus on, some of which aren't likely to be
possible without breaking a lot of code (most notably, the fact that strings
auto-decode to ranges of dchar), which is part of why there was a recent
discussion on creating a new version of Phobos that would eventually replace
the one that we have now
( http://forum.dlang.org/post/volmdaxjihbkpbtplynj forum.dlang.org ), but
even that discussion didn't exactly gain much traction, and changes that
require massive breakage in Phobos are unlikely to happen, even if we'd very
much like those changes, precisely because they'd cause massive breakage.

It's still possible to make changes in the language and standard library
without breaking everyone's code, and there's still plenty of room to make
some changes which are breaking changes if they bring enough value, but
there's a much greater focus on stability and avoiding code breakage than
there used to be, and having the massive breakage of redoing the standard
library or moving on to a new version of the language really doesn't fit in
with that. And we can do quite a lot in place without such massive breakage.
However, some folks are always looking for massive changes in the search of
making the language perfect. So, there will likely always be occasional talk
of moving on to D3, even if it is unlikely to be on the table any time soon,
if ever.

That being said, if you're expecting to be able to write D code and then
have it compile 10 years from now with whatever the current compiler is at
that time, you're likely to be disappointed. We're targetting stability, and
we're better at managing change than we once were, but there are still
occasional changes to the language, and even if the standard library is not
undergoing massive churn, it does change somewhat over time. If you're
maintaining your code and making the occasional, required adjustments when
the language or library changes something that requires adjustments, then
you should be just fine without having to do massive code rewrites or
anything like that (and at this point, breaking changes normally involve a
deprecation process so that they don't just force you to immediately change
your code). But if you write your code now and try and compile it in a few
years without maintaining it in the interim, then you're likely to have at
least some code which won't compile anymore.

- Jonathan M Davis
Jun 14 2017
parent reply Wulfklaue <wulfklaue wulfklaue.com> writes:
On Wednesday, 14 June 2017 at 09:18:58 UTC, Jonathan M Davis 
wrote:

 If you're maintaining your code and making the occasional, 
 required adjustments when the language or library changes 
 something that requires adjustments, then you should be just 
 fine without having to do massive code rewrites or anything 
 like that (and at this point, breaking changes normally involve 
 a deprecation process so that they don't just force you to 
 immediately change your code).


That is my point exactly. I have nothing against evolving a 
language slowly over time to include more features. A few things 
get obsolete, ... no big issue. New options are added. Again. No 
big issue.

But the moment a language opens up for developers their 
"wishlist", it seems everybody wants "their" changes added to the 
language. And this then turn into a language that is constantly 
changing. That is consider more the worst case scenario.

Frankly, if things are handled in a evolutionary way, then i do 
not have a issue with it. As long as thing do not turn out into: 
"well, x percentage of your code just become useless".
;)

The main issue is library vs existing code. There is a lot of 
code out there that is now abandoned but still (mostly) works. 
The moment the evolution gets too far, your starting to get more 
and more code out there that simple does not work.

In my personal opinion, if you want to pull something like that, 
then make a totally complete clean break. Change the language 
name ... And yes it sounds radical and silly but if there is one 
frustrating point that people have new to a language, is legacy 
non-functional code.

I can right now look up Swift examples and get over 50% that 
simply do not work because the language evolved so fast and 
everybody used the name "Swift", not "Swift 1.0", "Swift 2.0"... 
Its frankly a mess. And while i personally love some of the 
features that Swift has, its a mess for anything outside of the 
pure Apple development.

Just putting the cards on the table but frankly D is a generic 
name ( Mars was not much better ). When Googling for D code, the 
results are hit or miss. When Googling for Dlang, it tries to 
search on GoLang. Marketing is hard when your product is so 
generic named ( double pun is intended ) :)

Just changing the library to D3 and not the base D name will 
result in people finding old code, not getting it to work, 
getting frustrated and simply ignoring the language. Hey, despite 
loving the syntax, did the exact same thing with Swift.

With D i can find 3 or 4 year old code and get it running 
something without a single issue. Or a quick fix. Just saying, 
its not just about the language and library features. it also 
about what is round the language. The examples and code out 
there, the packages, the editors and other support.
Jun 14 2017
parent reply bachmeier <no spam.net> writes:
On Wednesday, 14 June 2017 at 11:34:09 UTC, Wulfklaue wrote:


 Just changing the library to D3 and not the base D name will 
 result in people finding old code, not getting it to work, 
 getting frustrated and simply ignoring the language. Hey, 
 despite loving the syntax, did the exact same thing with Swift.

 With D i can find 3 or 4 year old code and get it running 
 something without a single issue. Or a quick fix. Just saying, 
 its not just about the language and library features. it also 
 about what is round the language. The examples and code out 
 there, the packages, the editors and other support.


D3 isn't going to happen. I ignored this thread as a result. I 
only read the most recent posts because I wanted to see why it 
hadn't died. I doubt that Phobos 2 will happen either. All 
comments I've read from Walter and Andrei indicate that there are 
no plans for either.

I've been using D for four years. I can still compile code that 
compiled with DMD at that time, with only a few minor 
modifications. I expect to be able to do the same four years from 
now.
Jun 14 2017
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2017-06-14 at 11:57 +0000, bachmeier via Digitalmars-d wrote:

=20


[=E2=80=A6]

 I've been using D for four years. I can still compile code that=20
 compiled with DMD at that time, with only a few minor=20
 modifications. I expect to be able to do the same four years from=20
 now.


I suggest this is the wrong view of backward compatibility.

If you have a code that is never to change then you should archive the
compiler that compiled it along with that code. To demand that D must
never fail to compile ancient code is just wrong.

If a code is to be left untouched but the compiler not archived then
the code must be recompiled and amended as needed with each new
compiler that is accepted in the workflow.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jun 14 2017
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote:

 If a code is to be left untouched but the compiler not archived 
 then the code must be recompiled and amended as needed with 
 each new compiler that is accepted in the workflow.


I don't disagree with the general sentiment than one have to 
evolve the codebase along with the tooling, but if C, C++, Python 
and JavaScript didn't provide backwards compatibility in their 
maintained "production lines" then I most likely wouldn't use 
them and switch to something more stable...

So, I have no problem with Python going to Pyton3.x, as long as 
they update and maintain Python 2.7...
Jun 14 2017
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Ola Fosheim Grøstad wrote:


 On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote:

 If a code is to be left untouched but the compiler not archived then the 
 code must be recompiled and amended as needed with each new compiler 
 that is accepted in the workflow.


 I don't disagree with the general sentiment than one have to evolve the 
 codebase along with the tooling, but if C, C++, Python and JavaScript 
 didn't provide backwards compatibility in their maintained "production 
 lines"


at least C doesn't: almost all old-enough code is broken by various "UB".
Jun 14 2017
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Jun 14, 2017 at 11:45:43PM +0300, ketmar via Digitalmars-d wrote:

 Ola Fosheim Grøstad wrote:
 

 On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote:

 If a code is to be left untouched but the compiler not archived
 then the code must be recompiled and amended as needed with each
 new compiler that is accepted in the workflow.


 
 I don't disagree with the general sentiment than one have to evolve
 the codebase along with the tooling, but if C, C++, Python and
 JavaScript didn't provide backwards compatibility in their
 maintained "production lines"


 
 at least C doesn't: almost all old-enough code is broken by various
 "UB".


The difference is that unlike D deprecations, the C code will still
compile and appear to work (for the most part, anyway), thus giving
people the illusion that their old code is still "OK".  When actually,
the compiler may have done something unexpected with the UBs and thus
inadvertently introduced security holes.

Of course, none of this matters, since when was the last time bad C code
has caused security problems? :-P


T

-- 
I am a consultant. My job is to make your job redundant. -- Mr Tom
Jun 14 2017
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
H. S. Teoh wrote:


 On Wed, Jun 14, 2017 at 11:45:43PM +0300, ketmar via Digitalmars-d wrote:

 Ola Fosheim Grøstad wrote:
 

 On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote:

 If a code is to be left untouched but the compiler not archived
 then the code must be recompiled and amended as needed with each
 new compiler that is accepted in the workflow.


 I don't disagree with the general sentiment than one have to evolve
 the codebase along with the tooling, but if C, C++, Python and
 JavaScript didn't provide backwards compatibility in their
 maintained "production lines"


 at least C doesn't: almost all old-enough code is broken by various
 "UB".


 The difference is that unlike D deprecations, the C code will still
 compile and appear to work (for the most part, anyway), thus giving
 people the illusion that their old code is still "OK".  When actually,
 the compiler may have done something unexpected with the UBs and thus
 inadvertently introduced security holes.

 Of course, none of this matters, since when was the last time bad C code
 has caused security problems? :-P


yeah. D should silently miscompile old code too: it seems that this is 
exactly what people want!
Jun 14 2017
parent reply Wulfklaue <wulfklaue wulfklaue.com> writes:
On Wednesday, 14 June 2017 at 21:20:58 UTC, ketmar wrote:

 yeah. D should silently miscompile old code too: it seems that 
 this is exactly what people want!


Please point out the people who advocate for D silently 
miscompiling old code... Because i have yet to see anybody in 
this topic advocate this.

There is a difference between changes that:

- Fix bugs
- Fix security issues

And changes like

- Rewritten Library functions where those function calls end up 
working differently
- Removal of the Garbage collector ( and introducing ownership / 
lifetime and other rules )
- Changes that make tools not work anymore
- ...

It is this second part people worry about. If i need to fix code 
issues 5 years from now because the compiler got smarter, so be 
it. This will happen anyway with each progressive  bugfix / 
recompile. But there is a difference if massive rewrites are done 
on the language or libraries for that benefit only a few specific 
people there own usage.

So please keep this topic on track and not pull any straw man 
argumentation's. Its the internet and i know that some people 
like to win arguments with any means necessary but keep facts 
alive thank you very much.

I see nothing new being added to this topic anymore beyond more 
and more ridiculous claims.
Jun 15 2017
parent ketmar <ketmar ketmar.no-ip.org> writes:
Wulfklaue wrote:


 On Wednesday, 14 June 2017 at 21:20:58 UTC, ketmar wrote:

 yeah. D should silently miscompile old code too: it seems that this is 
 exactly what people want!


 Please point out the people who advocate for D silently miscompiling old 
 code... Because i have yet to see anybody in this topic advocate this.


we were talking about broken C code. that was a joke about what C commitee 
did with it's "UB" defintion, and allowing compilers to act as if code never 
ever can have "UB" in it.
Jun 15 2017
prev sibling parent reply bachmeier <no spam.net> writes:
On Wednesday, 14 June 2017 at 20:35:15 UTC, Ola Fosheim Grøstad 
wrote:

 On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote:

 If a code is to be left untouched but the compiler not 
 archived then the code must be recompiled and amended as 
 needed with each new compiler that is accepted in the workflow.


 I don't disagree with the general sentiment than one have to 
 evolve the codebase along with the tooling, but if C, C++, 
 Python and JavaScript didn't provide backwards compatibility in 
 their maintained "production lines" then I most likely wouldn't 
 use them and switch to something more stable...

 So, I have no problem with Python going to Pyton3.x, as long as 
 they update and maintain Python 2.7...


It's a bigger problem for D than for those languages. If you 
introduce too many changes, the tools stop working, and we don't 
have the manpower to fix them. The same goes for libraries. A 
language with a larger group of developers, like Python, can be 
less conservative about breaking changes and not have it disrupt 
the ecosystem.
Jun 14 2017
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 14 June 2017 at 22:01:38 UTC, bachmeier wrote:

 It's a bigger problem for D than for those languages. If you 
 introduce too many changes, the tools stop working, and we 
 don't have the manpower to fix them. The same goes for 
 libraries. A language with a larger group of developers, like 
 Python, can be less conservative about breaking changes and not 
 have it disrupt the ecosystem.


Yes, on the other hand, if you reach a stable version and stop 
adding features then you can focus on and reach maturity... Then 
leave the new features to the unstable version.

If you keep adding features to a stable branch then maturity is 
perpetually out of reach. I think Go gained a lot of ground from 
focusing on maturity over features.
Jun 15 2017
parent reply Suliman <evermind live.ru> writes:
Should D really move to GC-free? I think there is already enough 
GC-free language on the market. D even now is very complected 
language, and adding ways to manually managing memory will make 
it's more complicated.

A lot of people need more powerful static-typing alternative to 

executable files.

I think it's bad idea to mix to paradigms. People who do not need 
GC at all already use Rust.
Jun 15 2017
next sibling parent Wulfklaue <wulfklaue wulfklaue.com> writes:
On Thursday, 15 June 2017 at 15:04:26 UTC, Suliman wrote:

 Should D really move to GC-free? I think there is already 
 enough GC-free language on the market. D even now is very 
 complected language, and adding ways to manually managing 
 memory will make it's more complicated.

 A lot of people need more powerful static-typing alternative to 

 executable files.

 I think it's bad idea to mix to paradigms. People who do not 
 need GC at all already use Rust.


Actually, D already supports GC-Free / manual memory management.

https://dlang.org/phobos/std_experimental_allocator.html
+
 nogc
= manual memory management

The issue is that the std library is still full of GC parts and 
so is third party software. But you can simply turn functions and 
classes that do not use the library / 3th party software into 
pure nogc parts. Think of it more as a hybridize system.

I think there is somebody here who was writing a non-gc library 
for D.
Jun 15 2017
prev sibling parent reply Sebastien Alaiwan <ace17 free.fr> writes:
On Thursday, 15 June 2017 at 15:04:26 UTC, Suliman wrote:

 Should D really move to GC-free? I think there is already 
 enough GC-free language on the market. D even now is very 
 complected language, and adding ways to manually managing 
 memory will make it's more complicated.


We need automatic deterministic destruction (and we partially 
have it, using scope(exit) and structs RAII).

Memory management is only the tip of the iceberg of resource 
management ; it's the easy problem, where an automated process 
can to tell which resources aren't needed any more.

However, an instance of a class can hold a lot more than flat 
memory blocks: threads, file handles, on-disk files, system-wide 
events, sockets, mutexes, etc.

Freeing the memory of my "TcpServer" instance is mostly useless 
if I can't reinstanciate a new one because the TCP port is kept 
open by the freed instance (whose destructor won't be run by the 
GC).
Jun 15 2017
parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Thursday, 15 June 2017 at 17:06:31 UTC, Sebastien Alaiwan 
wrote:

 On Thursday, 15 June 2017 at 15:04:26 UTC, Suliman wrote:

 Should D really move to GC-free? I think there is already 
 enough GC-free language on the market. D even now is very 
 complected language, and adding ways to manually managing 
 memory will make it's more complicated.


 We need automatic deterministic destruction (and we partially 
 have it, using scope(exit) and structs RAII).


Not sure what exactly you are expecting, tbh. If you expect 
classes to be changed to behave like structs with regards to 
finalization: That can't happen, because they are reference 
types, not value types:
The lifetime of value type objects is statically known to end at 
their enclosing scope (unless they are moved), in contrast to 
reference types.


 Memory management is only the tip of the iceberg of resource 
 management ;it's the easy problem, where an automated process 
 can to tell which resources aren't needed any more.

 However, an instance of a class can hold a lot more than flat 
 memory blocks: threads, file handles, on-disk files, 
 system-wide events, sockets, mutexes, etc.


All of which you can easily take care of in the class' destructor 
and then .destroy such objects when needed.


 Freeing the memory of my "TcpServer" instance is mostly useless 
 if I can't reinstanciate a new one because the TCP port is kept 
 open by the freed instance (whose destructor won't be run by 
 the GC).


*might not be run by the GC when you want it to.

Why are you even talking about the GC when your problem seems to 
require deterministic lifetime management. That's not what a GC 
does, and thus it's the wrong tool for the job.
The right tool here would be one of
- std.experimental.allocator.{make,dispose} (statically known 
lifetime)
- {std.typecons / automem}.RefCounted (dynamic lifetime)
Jun 15 2017
parent Sebastien Alaiwan <ace17 free.fr> writes:
On Thursday, 15 June 2017 at 18:02:54 UTC, Moritz Maxeiner wrote:

 We need automatic deterministic destruction (and we partially 
 have it, using scope(exit) and structs RAII).


 Not sure what exactly you are expecting, tbh.


I'm not advocating for a language change here.
As I said, we already have some deterministic destruction (the 
rest being the GC).


 Why are you even talking about the GC when your problem seems 
 to require deterministic lifetime management. That's not what a 
 GC does, and thus it's the wrong tool for the job.


I don't have a programming problem ; I'm fine with unique and 
scoped!

I just wanted to make a point about how even GC-languages still 
benefit from some extra automatic and deterministic means of 
resource management.
Jun 15 2017
prev sibling parent reply bachmeier <no spam.net> writes:
On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote:

 On Wed, 2017-06-14 at 11:57 +0000, bachmeier via Digitalmars-d 
 wrote:

 


 […]

 I've been using D for four years. I can still compile code 
 that compiled with DMD at that time, with only a few minor 
 modifications. I expect to be able to do the same four years 
 from now.


 I suggest this is the wrong view of backward compatibility.

 If you have a code that is never to change then you should 
 archive the compiler that compiled it along with that code. To 
 demand that D must never fail to compile ancient code is just 
 wrong.

 If a code is to be left untouched but the compiler not archived 
 then the code must be recompiled and amended as needed with 
 each new compiler that is accepted in the workflow.


I'm not saying all old code should compile without changes, just 
that it should compile with only minor changes. I know that in 
some cases new releases of DMD have stopped compiling pieces of 
my code that shouldn't have compiled in the first place, and 
that's a good thing. On the other hand, dropping the GC would be 
a dramatic change that would require a complete rewrite. 
Libraries have to work with future versions of the compiler, 
especially if others are using them and can't make changes 
themselves.
Jun 14 2017
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2017-06-14 at 21:55 +0000, bachmeier via Digitalmars-d wrote:

 [=E2=80=A6]
=20
 I'm not saying all old code should compile without changes, just=20
 that it should compile with only minor changes. I know that in=20
 some cases new releases of DMD have stopped compiling pieces of=20
 my code that shouldn't have compiled in the first place, and=20
 that's a good thing. On the other hand, dropping the GC would be=20
 a dramatic change that would require a complete rewrite.=20
 Libraries have to work with future versions of the compiler,=20
 especially if others are using them and can't make changes=20
 themselves.


If D dropped the GC, then there wouldn't be a problem because there
wouldn't be any users. The GC is the single major factor for D in a
world of C++17, Rust, and Go: without the GC there is little point in
using D since C++, Rust, and Go have much more resources for
development of tools as much as of the language =E2=80=93 cf. CLion, Goglan=
d,
IntelliJ IDEA/Rust plugin to name just the JetBrains IDEs.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jun 15 2017
parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Thursday, 15 June 2017 at 07:32:42 UTC, Russel Winder wrote:

 The GC is the single major factor for D in a world of C++17, 
 Rust, and Go:


An opinion. Mine is this: The two major factors for D are (and 
have been for as long as I've been using it):
1. Productivity (i.e. focusing on writing actual problem solving 
code, not on dealing with language deficiencies)
2. Maintainability (i.e. still have that productive code look 
reasonable easy to understand a year from now without having to 
look up language deficiencies to understand why something *has* 
to look exactly the way it does, or introduce bugs)
The GC is nice in that it contributes to both of these points 
(and I have no desire to see it removed), but even without it 
there is no other native language (that I've tried as of yet) 
that comes even remotely close.


 without the GC there is little point in using D since C++, 
 Rust, and Go have much more resources for development of tools 
 as much as of the language – cf. CLion, Gogland, IntelliJ 
 IDEA/Rust plugin to name just the JetBrains IDEs.


Still an opinion, so here is mine again (based merely on personal 
experience):
Despite all those resources, someone having invested about the 
same amount of time in mastering C++(17), Rust, Go, and D will 
still end up being more productive in D, simply because, out of 
all of these languages, you have to fight D to do what you want 
the least.
Is D perfect? No, not by any stretch of the definition, but it is 
still (by far) the least worst choice out there, no matter how 
good the tooling for other languages is or becomes.
Jun 15 2017
parent ketmar <ketmar ketmar.no-ip.org> writes:
Moritz Maxeiner wrote:


 Is D perfect? No, not by any stretch of the definition, but it is still 
 (by far) the least worst choice out there, no matter how good the tooling 
 for other languages is or becomes.


exactly my feelings! ;-)
Jun 15 2017
prev sibling parent Sebastien Alaiwan <ace17 free.fr> writes:
On Tuesday, 13 June 2017 at 17:57:14 UTC, Patrick Schluter wrote:

 Before even contemplating a big disrupting language split like 
 proposed by the OP, wouldn't it first more appropriate to write 
 a nice article, DIP, blog, whatever, listing the defects of the 
 current language that can not be solved by progressive 
 evolution?
 I haven't the impression that the *language* itself suffer from 
 so big flaws that it would warrant to fork it in a way that 
 will lead to a lot frustration and bewilderment.
 D is not perfect, no question, but it is not in a state that 
 would jusrify such a harsh approach.


+1
Does anyone currently maintain somewhere such a list of 
not-gonna-be-fixed-in-D2 defects?
This might provide more solid grounds to this discussion.
Jun 13 2017
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
jmh530 wrote:


 Nevertheless, C++ is still a constantly evolving language.


one of the key features of evolution is removing old and rudimentary 
things. without this, it is not evolution, it is mutilation...
Jun 13 2017
prev sibling next sibling parent meppl <mephisto nordhoff-online.de> writes:
in my opinion starting with D3 is too early, because D-people 
dont even seem to know how exactly to implement new exciting 
features like "reference counting" (and how will "reference 
counting" work together with the new "scope"-feature?).

So, if a D3 gets developed _now_, i guess the compiler developers 
will create syntax issues again for those features and then we 
need a D4. Instead it might be better to collect more experience 
before thinking about D3
Jun 11 2017
prev sibling next sibling parent meppl <mephisto nordhoff-online.de> writes:
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:

 I realize that there are people who want to continue using D as 
 it is, but those people may continue to use D2. Putting the 
 breaking changes in a separate branch ensures that DM won't 
 lose current clients as they can just continue using D2 as they 
 are. Even after D3 is stabilized, D2 could have continued 
 support until nobody wants it.


sorry, i was overreading those lines of yours
Jun 11 2017
prev sibling next sibling parent solidstate1991 <laszloszeremi outlook.com> writes:
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:

 D is a language with much promise, but it still has many 
 problems that prevent it from being the great replacement for 
 C++ that it was always meant to be.

 There have been many changes suggested over time to improve the 
 language, but they were rejected as they would inevitably cause 
 breaking changes.  I think that breaking changes are something 
 to be careful about, and they can definitely be a nuisance to 
 adapt to.  But they must happen once in a while for things to 
 advance.

 I think it's about time for D3 to start developing.  So many 
 suggestions for language changes have accumulated by now so I 
 think that it's time to introduce to introduce the next wave of 
 breaking changes.
 It's nice to see that there's a wiki page that documents the 
 history of suggested language changes. I applaud the 
 organization.
 https://wiki.dlang.org/Language_design_discussions

 I realize that there are people who want to continue using D as 
 it is, but those people may continue to use D2. Putting the 
 breaking changes in a separate branch ensures that DM won't 
 lose current clients as they can just continue using D2 as they 
 are. Even after D3 is stabilized, D2 could have continued 
 support until nobody wants it.

 In Lua (a language with a bigger past and hopefully smaller 
 future than D), breaking changes are introduced in even minor 
 versions.  While I do think that's excessively frequent, there 
 are still users of Lua 5.1.  Making D3 doesn't mean that D2 has 
 to die.

 I feel like D3 would see significantly wider adoption than D2 
 ever got, as long as it successfully solves the problems of D2.

 Here are some ways that D3 can be an improvement of D2:
 -Final by default
 -A standard library that is effective with or without garbage 
 collection

 Even Andrei has admitted some issues with D when answering this 
 Quora question:
 https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why

 Even if you don't want to release a D3 too soon, I think it 
 definately makes sense to get started sooner rather than later.
  D3 should be developed for the same reason that D was first 
 developed; to make a better programming language that learns 
 from the problems of the one before.


I think we just should do those little fixes on D2 (eg. fixing 
the standard library, DIP45), instead of yet again reinventing 
the wheel. We have limited resources, I think first and foremost 
we should port the backend from C to D to further improve our 
productivity on the main compiler, then bugfixes and implementing 
non-x86 targets will be much easier.
Jun 11 2017
prev sibling next sibling parent aberba <karabutaworld gmail.com> writes:
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:

 D is a language with much promise, but it still has many 
 problems that prevent it from being the great replacement for 
 C++ that it was always meant to be.

 [...]


I anyone seeing the "i think"  "I think"...statements?

It's not something "you know". He doesn't mention "his" problem 
with GC.

I would like to know
Jun 12 2017
prev sibling next sibling parent reply Martin Nowak <code dawg.eu> writes:
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:

I'd be in favor of finally deprecating all sub-standard phobos 
module (moving them to https://github.com/dlang/undeaD) to make 
room for good implementations. Having a vacant place might be 
more encouraging than to wait for something better to come along.
Of course discussing which modules should be obsoleted is a 
tricky question.

std.signals
std.xml
std.outbuffer
std.socket
std.json // maybe ;)

I do not at all agree that a big language change is needed.
We just changed the lookup rules with 
http://dlang.org/changelog/2.071.0.html and managed to make this 
a transition instead of a break.
Also without a proposed feature list this discussion is somewhat 
lame.
Jun 14 2017
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2017-06-14 11:38, Martin Nowak wrote:


 Also without a proposed feature list this discussion is somewhat lame.


You only need one, AST macros ;)

-- 
/Jacob Carlborg
Jun 14 2017
parent Martin Nowak <code dawg.eu> writes:
On Wednesday, 14 June 2017 at 19:12:36 UTC, Jacob Carlborg wrote:

 You only need one, AST macros ;)


Not going to happen anytime soon, as we do not have much interest 
in DSL abuse.
Jun 18 2017
prev sibling next sibling parent Seb <seb wilzba.ch> writes:
On Wednesday, 14 June 2017 at 09:38:06 UTC, Martin Nowak wrote:

 I'd be in favor of finally deprecating all sub-standard phobos 
 module (moving them to https://github.com/dlang/undeaD) to make 
 room for good implementations. Having a vacant place might be 
 more encouraging than to wait for something better to come 
 along.
 Of course discussing which modules should be obsoleted is a 
 tricky question.

 std.signals
 std.xml
 std.outbuffer
 std.socket
 std.json // maybe ;)

 I do not at all agree that a big language change is needed.
 We just changed the lookup rules with 
 http://dlang.org/changelog/2.071.0.html and managed to make 
 this a transition instead of a break.
 Also without a proposed feature list this discussion is 
 somewhat lame.


Let's do this!

https://github.com/dlang/phobos/pull/5488
Jun 15 2017
prev sibling parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Wednesday, 14 June 2017 at 09:38:06 UTC, Martin Nowak wrote:

 On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray 
 wrote:

 I'd be in favor of finally deprecating all sub-standard phobos 
 module (moving them to https://github.com/dlang/undeaD) to make 
 room for good implementations. Having a vacant place might be 
 more encouraging than to wait for something better to come 
 along.
 Of course discussing which modules should be obsoleted is a 
 tricky question.


I just got done with watching this great presentation by Rich 
Hickey[1].
It's about change, how semantic versioning is broken, and why 
packages are wrong when it comes to dependencies.

In essence he is saying we should have immutable code releases. 
For example he would say that we should add a new namespace and 
not get rid of the original (std2.io, std2.xml, std2.json) now 
you can get your improvements out and not break anyone's code, 
for example he would say old modules would be deprecated but 
never removed.

I don't agree 100% with him but he does make good points. Really 
what I'm hearing out of it is that these semantic versioned 
packages should all be accessible from your code, when you 
upgrade the package you don't automatically start calling the new 
version of the functions but instead get access to those 
functions along with all the previous releases. But that is a lot 
of extra information to add to every function call:

     Package(arg, 1.4.2) foo(string i, int s) ...

1. https://www.youtube.com/watch?v=oyLBGkS5ICk&feature=youtu.be
Jun 15 2017
parent Martin Nowak <code dawg.eu> writes:
On Thursday, 15 June 2017 at 18:26:57 UTC, Jesse Phillips wrote:

 In essence he is saying we should have immutable code releases. 
 For example he would say that we should add a new namespace and 
 not get rid of the original (std2.io, std2.xml, std2.json) now 
 you can get your improvements out and not break anyone's code, 
 for example he would say old modules would be deprecated but 
 never removed.


Not much different from moving old code to Undead, requires very 
little work.
On a plus side you have to decide whether to upgrade your code or 
stick with the existing modules.
Jun 18 2017
prev sibling next sibling parent reply Mike <none none.com> writes:
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:


 I think it's about time for D3 to start developing.


I would love to see a fork of D2 that attempts to address some 
obstacles I encountered when I was using D.  However, it is quite 
apparent that there is little to no interest in such a venture 
from those in the D community with the talent to actually do it.  
And I have to admit there is still room for innovation in D2, and 
that seems to be where most want to allocate their limited 
resources.

For D3 to happen, it will likely require talent outside D's core 
team.

I do a lot of programming in different domains, and it seems I 
have to use a different language for each one in order to be 
productive. I would like to find a single language that I can use 
to program just about any domain, but still be able to enjoy 
modern features for safety, convenience, zero-cost abstractions, 
and modeling power.  I'm not aware of any language that fits that 
description, but the languages I've found to be somewhat close 
are C++11~17 and Rust.  They're the only ones that appear to be 
scalable down to domains such as resource constrained 
microcontrollers.

* Using D for resource constrained systems requires too many 
compromises and silly runtime hackery.
* C++11~17 is quite good but it is not at all convenient, and 
safety is just too easy to get wrong.
* Rust is probably the best, but it doesn't have the modeling 
power of D and C++.

It'd be more constructive to begin collecting information from 
the community about what changes they'd like to see in D3.  
Here's a start from things just off the top of my head and in no 
particular order.

THINGS TO CHANGE OR ADD
-----------------------
* Final-by-default

* immutable by default

*  safe by default

* Fix attribute inconsistency and revisit if D is using the 
appropriate defaults

* Pay as you go druntime.
The compiler is too coupled to druntime and expects things to be 
there even though they're not required.  This would also make D a 
better language for replacing much of the exising infrastructure 
code out there that is currently written in C because it wouldn't 
require the D runtime dependency and all the overhead that goes 
with it.  Rust has done well in this regard.

* Minimal druntime
The language should be easy to port to other platforms.  Keep 
druntime small and to a few fundamental primitives to whatever 
extent that is possible.  Rust has also done well in this regard.

* Compiler resolves druntime symbols at compile time.
This is important for porting D to other platforms that may not 
have the resources or hardware to support certain features of the 
language.  The compiler would emit a compile-time error if usage 
of such a feature was attempted, but not supported by the 
runtime.  Proposed here [1].

* Some way to mark memory at compile-time with certain attributes 
(e.g. See [2]) to inform the compiler of proper code generation 
(e.g. volatile semantics).  This would probably only be useful 
for bare-metal programming, but I encounter this all the time and 
its getting worse with each new MCU generation.

* Remove the "module must be a file" arbitrary limitation
I ran into this when I was trying to model hundreds of 
memory-mapped IO registers.  I wanted to use a module for each 
register, but each module would only have a small amount of code, 
and I would have ended up with hundreds of little files.  It 
would have been better if I could group all "register" modules 
for a given peripheral under one "peripheral.d" package file.  
Something like `package UART { module SR {} module DR{} }` would 
have been nice.  I ultimately ended up with `final abstract class 
{}` instead, which is stupid.

* get rid of the "_t" suffix added to types from C.
Come up with a better, more consistent naming convention for 
these types that doesn't carry baggage from other languages.

* Drop the GC or at a minimum make it opt-in.  Add a borrow 
checker, automatic reference counting, or some other GC 
alternative that doesn't require a separate thread.
DIP1000 is interesting and may enable some new interesting 
patterns and idioms.  Might be able to take some inspiration from 
it.  I wonder if DIP1000 would have been more elegant if D didn't 
have to worry about breaking code.

* The C standard library bindings and C++ standard library 
bindings should be in Deimos not in the druntime.
I already tried to promote this, but only encountered obstruction.

* Cure the TypeInfo infection [3]
TypeInfo has been over(ab)used in the runtime implementation.  
This is probably due to historical baggage, but also a lack of 
discipline.

THINGS TO KEEP
--------------
* CTFE

* Templates and static-if (static-if is some powerful stuff!)

* Mixins (or some other way to do convenient composition)
I get that one should favor composition over inheritance, but 
most object oriented languages offer precious little to do the 
"right" thing.  D mixins are great for composition.

* Traits (or some other form of reflection)

* UFCS

THINGS TO DROP
--------------
* C++ interoperabiliy
Walter's right:  memory safety is going to kill C and C++ will go 
with it.  Don't waste time on this; it's not going to matter in 
10 or 20 years.

After collecting such a list, begin a fork of LDC, and start 
working on it.  If you can show progress and potential, others 
may be willing to contribute, accelerating the project.  I, 
personally, think it would be very exciting to see and would 
eventually become an active contributor myself if the project 
addressed some of the issues I have with D2.

I was on cloud 9 when I first started using D, and had high hopes 
that it would change my career and even give me a new tool off 
which to build a profitable business.  But the more I used it, I 
just became more disillusioned.  D has so much potential compared 
to all other languages out there, but it's potential that it will 
never reach because it's just carrying too much baggage and has 
not been designed with domains like resource constrained 
microcontrollers in mind, like Rust was.

I don't do anything in D anymore, but I still watch what goes on 
here in the D community, and hope that someday enough people will 
come together and begin a fork to take D to its true potential.  
I don't have the skills or resources at this time to lead such a 
project, but I'll volunteer my resources if it ever gets off the 
ground and shows promise.

Mike

[1] - Proposal to have druntime inform compiler of platform 
support - 
http://forum.dlang.org/post/psssnzurlzeqeneagora forum.dlang.org
[2] - ARM Cortex-M3 memory attributes - 
https://developer.arm.com/products/processors/cortex-m/cortex-m3/docs/dui0552/latest/2-the-cortex-m3-processor/22-memory-model/221-memory-regions-types-and-attributes
[3] - Discussion about the TypeInfo infection - 
http://forum.dlang.org/post/nevipjrkdqxivoerftlw forum.dlang.org
Jun 14 2017
next sibling parent Wulfklaue <wulfklaue wulfklaue.com> writes:
On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote:

 * Rust is probably the best, but it doesn't have the modeling 
 power of D and C++.


A lot of the points you mention, i also agree with but 
implementing that list is akin to writing a new language. You do 
not trow out the baby with the bathwater ;)

 From what i am reading, you want D to be Rust. Personally, Rust 
make me want to tear out my eyes the moment you start with 
lifetimes, unwrapping and ownership all combined , its becomes 
almost unreadable.


    fn the_longest<'a>(s1: &'a str, s2: &'a str) -> &'a str {
        if s1.len() > s2.len() { s1 } else { s2 }
    }


Rust really skips on the syntactic sugar *lol*.

If people want a low level language for microprocessors/plc, well 
they already got C++14/17 and Rust. D can carve its own market 
segment no? Why complicate D for one specific market segment?

There are defiantly nice point that you mention but dropping 
C/C++ support is like a dead sentence. D does not have the 
manpower and  libraries that people may need.
Jun 14 2017
prev sibling next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote:

 * immutable by default


I have to admit I always get confused why people get so invested 
in this. It seems like you would have to completely redesign 
everything related to std.range/std.algorithm.
Jun 15 2017
prev sibling next sibling parent reply Liam McGillivray <yoshi.pit.link.mario gmail.com> writes:
On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote:

 THINGS TO DROP


 --------------
 * C++ interoperabiliy
 Walter's right:  memory safety is going to kill C and C++ will 
 go with it.  Don't waste time on this; it's not going to matter 
 in 10 or 20 years.


Thank you for making a list to give people an idea of what D3 
could be, but I definitely don't support less interoperability 
with C++. I want D3 to have a better argument to transition from 
C++ than D2 has.  With all the C++ API's out there, making D 
incompatible would be a ginormous deal-breaker for a ridiculous 
number of projects.  D3 should seek to be worth the transition 
from C++.

For those who say that this idea can't go anywhere without an 
idea of what changes it would make, I'll relink to the page I 
already posted.  There are many proposals that were rejected due 
to "breaking changes" that should be relooked for D3.
https://wiki.dlang.org/Language_design_discussions

People who say they like D2 for "stability" don't need to worry.  
What would be a threat to stability is breaking changes in D2.  
But that was never allowed, so you must not worry.  If D3 was 
released, you may still use D2 just as you would have otherwise.

For the people who talk about D3 being an alternative to, rather 
than a replacement for D2:
I think that D3 should seek to be a better option than D2 for 
virtually every new project.  If done right, it will barely split 
the community; I'm hoping for D3 to expand the popularity of D to 
overshadow what D2 ever was.  Improving some things in D would 
make it an easier sell to C++ programmers, even in converting 

main goal of D3 is to significantly shrink the number of 
scenario's in which C++ is more viable than D (to less than one 
third. Not "more viable" in the opinions of the D fanatics here, 
but to everyone who properly considers D vs C++.  I feel like D 
only needs one more major (breaking) revision to do this, and it 
would be a less dramatic change than D1-D2.

For those who are saying that everything is right with D2, I want 
to point out that there is a bias to the people in this forum.  
It is that people posting here tend to be "insiders", who don't 
mind/see the problems that discourage others from using D.  There 
are surely many "outsiders" out there (not reading this) who have 
considered D in the past, but chose C++ instead for valid reasons.
I recommend searching the internet for others opinions on D.  You 
may find disadvantages of D apparent to other programmers that 
you never thought of.  Have you ever talked to a C++ programmer 
about what they think of D, and why they don't use it?

Also, I must say that although D is often discussed as a "systems 
programming language", I also have high hopes for it as an 
application programming language.  Once it's more widely 
supported, it can significantly lower the barrier-of-entry for 
programming.  People naturally gifted at programming probably 
don't realize how ridiculously high the barrier of entry is for 
most people, even those who are interested.

I hope that Walter and Andrei give a proper response to this 
thread.  I wonder why they haven't.
Jun 16 2017
next sibling parent reply Suliman <evermind live.ru> writes:
On Saturday, 17 June 2017 at 04:32:41 UTC, Liam McGillivray wrote:

 On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote:

 THINGS TO DROP


 --------------
 * C++ interoperabiliy
 Walter's right:  memory safety is going to kill C and C++ will 
 go with it.  Don't waste time on this; it's not going to 
 matter in 10 or 20 years.




Totally agree! C++ now in 90% of cases is legacy projects. At 
current time is more important to out of the box interoperability 
with Rust or Julia. Time show that C++ do not want to migrate to 
D. Only few people come from C++ world, because all of them 
waiting of new C++ standard c++x2035 (or whatever)
Jun 16 2017
parent reply Liam McGillivray <yoshi.pit.link.mario gmail.com> writes:
Removing all C++ compatibility is a death sentence for D.  This 
may not be apparent to some people that already program in D, but 
it is downright critical to potential D users.  Zero C++ 
compatibility means that D can no longer interface with C++ 
libraries such as Qt, putting a severe limitation on it's uses.

At the very least, dropping C++ compatibility is not for D3.  If 
ever, it should happen when D is already as popular as C++.  I 
brought up this whole D3 idea because I feel like D just needs 
one more wave of breaking changes to the language and library to 
be brought to perfection.  There are many C++ programmers out 
there who looked into/tried D and felt like it was almost good 
enough.  I think it will just take one major breaking version to 
make them jump, but not if it's totally incompatible with C++.

D3 should make the changes that can be agreed between proud D 
users and C++ users who have hopes for D.

On Saturday, 17 June 2017 at 06:23:08 UTC, Suliman wrote:

 On Saturday, 17 June 2017 at 04:32:41 UTC, Liam McGillivray 
 wrote:

 On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote:

 THINGS TO DROP


 --------------
 * C++ interoperabiliy
 Walter's right:  memory safety is going to kill C and C++ 
 will go with it.  Don't waste time on this; it's not going to 
 matter in 10 or 20 years.




 Totally agree! C++ now in 90% of cases is legacy projects. At 
 current time is more important to out of the box 
 interoperability with Rust or Julia. Time show that C++ do not 
 want to migrate to D. Only few people come from C++ world, 
 because all of them waiting of new C++ standard c++x2035 (or 
 whatever)


Please don't quote me just to say "Totally agree!" to someone 
that I quoted and disagree with.

A prediction that C++ is going to be dead in 10 years is not good 
enough.  C++ is very active, not just legacy like you say.  As I 
said, D should not drop compatibility until it's ALREADY clear 
that it's getting surpassed by D.
I support interoperability with Rust if it's doable.  I barely 
know about Julia.

Like I said, there are actually many C++ programmers out there 
who feel like D2 has promise, but not quite there.  THIS is why I 
brought up this D3 idea.  I really do think that D3 could bring 
quite some excitement to the programming community if it's coming 
along well.  After a few of the more open-minded C++ programmers 
adopt D, it will trickle up to more and more.
Jun 17 2017
parent reply Suliman <evermind live.ru> writes:
Why for example not Rust (i am not its fan). I do not see any 
real perspective in C++. What to do in next 5 years if C++ will 
start loosing it's popularity? Implement D4?

Plus any backwards compatibility make implementation new ideas in 
language very hard.
Jun 18 2017
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 18 June 2017 at 07:14:24 UTC, Suliman wrote:

 Why for example not Rust (i am not its fan). I do not see any 
 real perspective in C++. What to do in next 5 years if C++ will 
 start loosing it's popularity? Implement D4?

 Plus any backwards compatibility make implementation new ideas 
 in language very hard.


Both C/C++ are loosing popularity relatively speaking, but this 
is not because of the languages themselves. It is because more 
and more applications can be written either fully or in part in 
higher level languages.

So C++ is taking over parts of the former C domain, and other 
high level languages are taking over some parts of the C++ 
application development domain.

But C++ will still be big in 10 years.
Jun 18 2017
parent reply Suliman <evermind live.ru> writes:
 But C++ will still be big in 10 years.


Ok, let's assume it will be poplar in 10 years. But it's very 
short time. D exists almost 17 years.

And not every people need to interfacing with C/C++. For me it's 
more important to have static-typing and compilable alternative 
to Python. And a lot of people whom I know want same.
Jun 18 2017
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 18 June 2017 at 12:05:37 UTC, Suliman wrote:

 And not every people need to interfacing with C/C++. For me 
 it's more important to have static-typing and compilable 
 alternative to Python. And a lot of people whom I know want 
 same.


I see this a lot, but then you have to ask yourself how many 
languages are trying to enter the same domain (faster Python).

In the end a language has to be the best for some particular 
domain to gain traction.
Jun 18 2017
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 17 June 2017 at 04:32:41 UTC, Liam McGillivray wrote:

 I hope that Walter and Andrei give a proper response to this 
 thread.  I wonder why they haven't.


They rarely give definitive answers... except after the fact, 
once it is already in master.
Jun 17 2017
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 17 June 2017 at 04:32:41 UTC, Liam McGillivray wrote:

 On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote:

 THINGS TO DROP


 --------------
 * C++ interoperabiliy
 Walter's right:  memory safety is going to kill C and C++ will 
 go with it.  Don't waste time on this; it's not going to 
 matter in 10 or 20 years.


 Thank you for making a list to give people an idea of what D3 
 could be, but I definitely don't support less interoperability 
 with C++. I want D3 to have a better argument to transition 
 from C++ than D2 has.  With all the C++ API's out there, making 
 D incompatible would be a ginormous deal-breaker for a 
 ridiculous number of projects.  D3 should seek to be worth the 
 transition from C++.


Seems like there is a split right down the middle. The problem is 
of course that going down the middle is neither satisfactory nor 
innovative.

I agree with you, but I think the C++ compatibility is a lost 
game and increasingly so without aligning the core semantics. C++ 
is changing too...
Jun 17 2017
prev sibling parent Nick Treleaven <nick geany.org> writes:
On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote:

 * Drop the GC or at a minimum make it opt-in.  Add a borrow 
 checker, automatic reference counting, or some other GC 
 alternative that doesn't require a separate thread.


AIUI D's GC doesn't use a separate thread:
https://dlang.org/spec/garbage.html#how_gc_works

"1. Stopping all other threads than the thread currently trying 
to allocate GC memory.
2. ‘Hijacking’ the current thread for GC work."

An earlier bullet point is confusing:
"Normally, all threads other than the collector thread must be 
halted while the collection is in progress."

Probably 'other than the collector thread' should be removed - 
'collector thread' implies asynchronous collections.
Jun 19 2017
prev sibling parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
 Here are some ways that D3 can be an improvement of D2:
 -Final by default
 -A standard library that is effective with or without garbage 
 collection


100% OK about the optional garbage collector, but I have to 
totally disagree with you on the "final by default" approach.

The current design keeps the code open to extension, in a 
perfectly complementary way to UFCS.

They are both incredibly useful, and are part of what makes D2 
perfectly work as a strongly-typed JavaScript-like scripting 
language.

(I just had another proof of that this morning, see my recent 
post.)

And dropping C++ compatibility is a complete non-sense IMHO.

If you want more people using D, its interoperability with C and 
C++ should instead be improved, so that D applications can 
quickly and easily use any C/C++ 3D/2D/VR/audio multimedia 
libraries for instance...
Jun 18 2017