On Thursday, 22 February 2018 at 14:36:10 UTC, Radu wrote:
Whould like to know what's the state of dip1000?
The fact that it takes 8 days for any reply, doesn't that say
something?
@safe is a high ranked technical issue in vision papers (in
german we say something like "paper is patient"), but when trying
to turn to reality and push forward dip1000 for phobos (as I did
in the past ~1.5 month), only a few members like Seb really seem
to care a lot.
Lately I haven't noticed much activity on it, and at least on
the bug front there are about 28 entries opened:
https://issues.dlang.org/buglist.cgi?quicksearch=dip1000%20OR%20%5Bscope%5D&list_id=219758
Look at my #18444 and it's "Depends on" and exclude 18444 from
counting: It's just a tracking/organizational issue intended to
i.a. perhaps add help for "dmd coder's" priority. No observable
reaction there since Feb 15 so far. And there are others that I
wouldn't take into account as bugs. My first reaction looking at
this list again now is: Most issuers expect "somethÃng to happen"
on the dmd part.
I'm asking this as I am eagerly waiting for it for about 1
year, wanting to use it for a new project that is in pipeline,
and no major progress has been made since last year on both
finalizing the spec and using the implementation in
Phobos/druntime.
IIRC, druntime is compiled -dip1000 already and for phobos, have
a look into the aa settings in PR 6195: Only "a few" phobos
modules are not -dip1000 compilable, currently.
I'm also awaiting -dip1000 compilable phobos, and we are now 10
month past Walter Bright's DConf2017 talk "pointers gone wild",
where he said "-dip1000 is implemented already" (omitting what's
missing). From an eMail conv. with a member I know, Walter is
aware of missing pieces in DIP1000.md and implementation and that
it's on his TODO-list, probably as many other things are as well.
But, except for special cases, there is no reason not to use
-dip1000 today:
-dip1000 implementation is far better than it's reputation.
I generally already used -dip1000 since DConf2017 and it served
me well, until about 2 month ago, "by accident" code was
committed to std.uni that broke my builds, see issue #17961. I
invested a lot of time to fix this by PR 6041.
The current state is: I don't know any reason why it doesn't get
(can be?) merged and now it languishes on page 2 of 3 of PRs and
Walter started a new PR 6212 recently after my PR is ready for
weeks. In total 4 of my -dip1000 related PRs are stuck and mostly
for unknown or arguable reasons.
Knowing my experience now, You won't expect me to contribute for
-dip1000 any longer, but of course, You may do so and perhaps
have more luck.
There's a nice german children's song that comes to my mind here:
"Ein Loch ist im Eimer".
known in english as: "There's A Hole In My Bucket".
It just leaves me stunned, shaking the head.
Are there major roadblocks ahead? Or is just a matter of
prioritization/budget?
I would say (biased as I am), these are roadblocks:
1. Lack of (sufficient/knowledgeable) compiler contributors.
2. Some lack of coordination/enforcement/management: vision <->
make it happen.
3. A tendency to scare away (impatient,) possibly long-time
contributors, i.a. - as I perceive that - by lack of
appreciation, instead taking for granted volunteer contribution
(which shows up in complete unresponsiveness sometimes: When I
spend e.g. > 1 day on a non-trivial D-Programming-Deimos issue
and there is no reaction to my PR for 2 month, not even a 1
minute response like "sorry no time" or "doesn't LGTM
because...": That's at least impoliteness (I take it as lack of
appreciation) that I won't accept any more. On the other hand,
for "trivial" PRs, You may get very quick replies from 2 members.
From DConf2017 talk "Systems Programming Panel" I know, I'm not
alone being discouraged.
(It may be absolutely unrelated, but there once was a very
productive and knowledgeable compiler et. al. contributor, 9rnsr,
Hara Kenji; though not contributing to dmd since ~ 1.5 years any
more, he's still ranked #1 in number of contributions; I think,
he's a busy professor at a Tokyo university, but I'm really
curious to know why he stopped coding; I guess, dmd improvement
speed still suffers from his decision).
Though this might have raised more questions than giving answers
(to the time schedule): Was it helpful?
